[Cryptography] Do capabilities work? Do ACLs work?

[Nico Williams]

On Tue, Feb 10, 2015 at 12:52:58PM +0000, ianG wrote:
> On 10/02/2015 04:59 am, Ben Laurie wrote:
> >As Bill points out, this is exactly the point of capability systems (he
> >didn't say it, but it is what he meant). A long time ago we had a choice
> >between ACLs and capabilities, and we chose the wrong thing.
> >
> >Capability systems do exist, but we also have a lot of ACL-based
> >engineering to fix in order to properly use them.
> 
> Having watched/worked with capability ideas for a while, I'm of the
> opinion they don't work as well in practice as the theoretical
> pundits would have it.

Capabilities in the academic (i.e., not Linux) sense are great, but we
don't have enough real-world experience with them because, as you say,
ACLs won out.  iOS uses a limited form of capabilities, and this is
clearly superior to Android's privilege model.  But does the iOS model
scale out to large enterprises?  Where Windows and Linux rule, all we
have are ACLs, and to a much, much smaller degree, some flavor of MAC.

> Also, the users continue to demand ACLs.

Users generally don't want to think about ACLs.  Someone has to though.

Also, from a management perspective, understanding capability usage can
be very difficult (or so I imagine, since I lack real-world experience
with capabilities at an enterprise scale).  Ditto ACLs, but if mgmt can
audit ACLs at a coarse-enough level (something like "share-level ACLs",
if you wish), then they can manage.  See below.

> So my current view is that what is needed is a hybrid.  At a limited
> sense one can see this with expiries:  a cap with a time limit on it
> is a cap with a "control" on it.

iOS-like systems could certainly use time-limited capabilities, IMO, yes.

There are a lot of things we could do.  The app isolation model leads to
interaction being moderated by capabilities and/or ACLs, but the main
thing there is application isolation.  Interaction moderation via
priviliges, of course, is a bad idea.

> In a more developed sense, my software has lots of caps running
> around, but servers that serve those caps also look at who's asking.
> E.g., when Bob looks at Alice's photo, the server only grants it if
> Bob is in Alice's A list.
> 
> This certainly makes for more complicated software.  But when the
> judge asks, it's much easier to say "only Bob could have seen the
> photo" than anyone with a cap...

Exactly.  Understanding such a system requires inquiring as to its
internal run-time state if it uses capabilities, but not if it uses ACLs
[presumably stored in external state].

> ps; a capability in the sense I mean above is implemented by an
> object which is hashed canonically and stored somewhere on the net.
> If you have the hash, you can ask the store to reveal it.

The indirection to find locations costs a lot.  Caching of location
information is a partial solution.

Revocation is hard, but that's because revocation is hard (once you give
some entity access, they have at least an analog hole).

Nico
--