[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

On Dec 27, 2008, at 7:35 PM, David-Sarah Hopwood wrote:
> That's true to a certain extent. The main deficiency of this  
> approach is
> that you end up with a system in which it may be possible to bypass  
> the
> capability layer by taking advantage of flaws in other layers. There
> are also impedence mismatches between the layers that use different
> access control approaches. For these reasons, I consider it only to be
> a short-term solution.

Of course, these are concerns, but as Voltaire said, "Le mieux est  
l'ennemi du bien" (the perfect is the enemy of the good).  The  
emphasis I've seen on top-to-bottom capability systems I believe has  
impeded the spread of capability security ideas in practice, and the  
net result is capability security remains a relatively little-known  
and little-practiced architectural approach, when in fact, in my view,  
it can and should be practiced right now, in production systems, as  
Monty and I and the rest of us have done at our startup, as Google has  
with the Caja project, and as I've done in another project I can't  
discuss yet.  Capability security, even implemented in just one layer,  
can solve very real, practical security problems today (the project I  
can't discuss had been wrestling with these problems for months prior  
to my arrival on the project --- and capability security turned out to  
be just the solution they were looking for).

Whenever you have any sort of scriptable system (for example, the Caja  
folks dealing with Javascript) there's a vast space of potential  
attacks that can occur even when the layer in question is operating  
perfectly (i.e., even if you aren't relying on bugs in the underlying  
system, buffer overflow errors, etc.)  Making the programmable layer  
itself capability secure can enable authority management techniques  
that are simply impossible with role-based security, and enable  
sharing of libraries and other code with far less risk.  Of course,  
there's always the possibility the layer can be breached, but my point  
is even a correctly functioning layer, written using role-based  
security, can pose huge risks, and in fact those risks dominate the  
security picture.

The "impedance mismatch" is also far less of a problem than it may  
seem, it turns out, for reasons I won't elaborate on in detail here,  
but in brief it's because once you wrap an external ACL-based service  
in a capability (which can have arbitrarily complex code controlling  
access), the laws of capability authority transfer then take over.   
You really don't have to think in terms of ACLs at all, or the fact  
that the service itself is unaware of the capability wrapper, from the  
POV of the layer it is pure capabilities.

>> I think this strategy ought to be applied far more frequently; [...]
>
> I agree with that, but possibly for a different reason: replacing  
> layers
> individually is probably the only practical way to get to a top-to- 
> bottom
> capability system in the longer term.

I'm simply going to have to disagree here, quite strongly.  A well- 
implemented capability security layer can be a huge boon for its own  
reasons.  I agree that in the long run, a top-to-bottom capability  
world may well be desirable, but I suppose I quite disagree that this  
is the main reason to build capability layers.  Capability security  
layers have their own powerful semantics which are immensely useful on  
their own terms, and at the same time would serve to propagate the  
concepts to the larger engineering world.  I was asked once when I  
presented some of my ideas to one senior engineer, "If capability  
security is so great, why hasn't it been more widely adopted by now?"   
I said I really didn't understand it myself, since it's so useful, but  
I thought one reason is there's been too much focus on "pure" top-to- 
bottom systems, and not enough on implementing layers and wrappers,  
despite the fact that layers and wrappers can give you a lot of benefit.

>
>
> -- 
> David-Sarah Hopwood ⚥
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk