[Cryptography] Do capabilities work? Do ACLs work?

[Rob Meijer]

2015-02-17 12:24 GMT+01:00 Jerry Leichter <leichter at lrw.com>:

> 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.
>


​Yet when you look at both tuples and file-systems as directional graphs,
the two worlds can meet once more in  (hopefully) multi-granular usable
patterns.

Here is my attempt at an algorithm and library for use in a simple
(sparse)capability based file-system:

​
https://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children-part-2/
http://pibara.github.io/Rumpeltreepp/

I don't have a background in cryptography so there is probably room
for improvement, but the base idea could be usable for tuples , file
systems and other DAG shaped singly attenuable structures.



>                                                         -- Jerry
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150217/a491864b/attachment.html>