[Cryptography] Do capabilities work? Do ACLs work?

[Jerry Leichter]

On Feb 17, 2015, at 12:35 AM, Bill Frantz <frantz at pwpconsult.com> wrote:
>> It's also the case that we've spent so many years on the debate of ACL's OR capabilities that we've closed our eyes to the limitations of *both* - and, indeed, of the underlying access matrix model.  Relational database systems, and the security policies appropriate to them, don't fit either; and, indeed, the usual way to define access policies in RDBM's (beyond simple ones that are usually done in a style that's mainly ACL-like) is to define a query that gets combined with a user's query, filtering out the results that are not supposed to be accessible.  (I guess, looking back, that that style of doing things led me to the Area 51 problem.)
> I really have no idea of the issues in database security.
A whole other world.  Interestingly, most of the work tends to center on reading - a database by its nature is usually filled by some background process that has very broad rights, but is then available to a large number of individuals how have varying access rights.

A very simple policy might be:  An individual can only read his own salary and that of people who work for him.  Keep in mind that "work for him" is stored in the database itself.  In general, *everything* is stored in the database itself.  So you could have a policy like:  A person can only see the salaries of people who make no more than he does.  (I actually used a system with a policy that you could only see "target salary" ranges for "bands" of salaries below your own.  People found a hack - I can't recall how it worked - that actually let you see your own band's "target" range. BTW, this was, of course, restricted to "managers" - there were nominally parallel tracks for managers and technical people, but no matter how high on the technical track you were, the "manager" stuff was closed to you.  And what defined a manager?  That was in the database, too:  A manager was anyone who had at least one person reporting to him.)

It's because everything is in the database system itself that the natural way to define policies is by adding to each user query a further filter using the DB language itself.

There's been a whole ton of work on how to allow access to statistical information without allowing access to individual information - e.g., average income in a census tract but not the income of any one person.  But you want that combined with other selections, like average income for men vs. women in a census tract.  Unfortunately, it turns out this is unachievable - with any kind of reasonable query mechanism, it's possible to produce sets of queries that zoom in on an individual.  (The phrase to look for is "trackers in database systems".)  But of course this has led to alternative formulations of the problem and some practical solutions.

Returning to cryptography, there's all sorts of interesting work on enforcing some constraints cryptographically - how to have a tuple of data that's encrypted as a whole, but such that you and I have keys that can only decrypt some fields but not others.

A very different world than OS's.
                                                        -- Jerry