[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

On Dec 29, 2008, at 2:09 PM, David-Sarah Hopwood wrote:
> I disagree. Complexity is the enemy of security, and it's not possible
> to make a system simpler by adding layers. Since an ACL layer is
> typically already too complicated, it is only by removing such layers
> that we can obtain a high degree of confidence in the security of the
> whole system.

I'd just ask that you try to keep an open mind about this because I  
know the result we're trying to report here is quite surprising, but I  
think if you consider it more carefully you'll see the merit.

When you say "it's not possible to make a system simpler by adding  
layers" I think I understand where you're coming from, but think this  
through more deeply.  Even a fully top-to-bottom capability OS is in  
itself a simplifying layer on top of the raw bits of the underlying  
computer or network of computers.  Imagine trying to "secure" a system  
where users were allowed to directly program to the hardware level in  
binary.

All security approaches, whether capability-based or ACL-based, are  
implemented at some layer of abstraction above another, chaotic, and  
highly insecure layer.  Whether that layer is the underlying raw bits  
on the hard drive or in RAM, or it is a pre-existing ACL-based system,  
is rather arbitrary.

So I agree the enemy of security is complexity, but *every* approach  
to simplifying that complexity involves writing a layer of some kind.   
What makes the layer simple is its internal structure, combined with  
whether or not there are holes in the layer.  For example, even a top- 
to-bottom capability OS might have a bug in it that would allow access  
to the underlying bits in RAM or on the hard drive -- in which case  
the top-to-bottom capability OS would be vulnerable, again.  Even if  
one were to build a capability secure CPU, there could be a bug in the  
CPU's hardware design!  So you cannot completely eliminate risk even  
with a so-called "top-to-bottom" design.

What you can do, however, is build a layer that *itself* is based on  
capability security principles.  That, I would argue, is what every  
approach to capability security involves, not just the approach my  
colleagues and I have used in our designs.

In more concrete terms, a capability wrapper around an ACL-based  
resource acts in every way like a pure capability from the layer's  
POV.  I.e., it's no different from a top-to-bottom system in which  
one, for example, defines a capability to access, say, a database.  In  
a wrapper, the interface is a wrapper with role-based credentials ---  
however these credentials are only visible to the creator of the  
capability (who must have ordinary ACL permissions to do so) --- but  
then you can give out this capability in a capability secure manner.   
For example, one can grant the capability to access the DB in a  
restricted fashion (throttling access, for example), or one can revoke  
access (via a proxy switch) and the grantee never has access to the  
ACL-based permissions.  Even the capability to *create* database  
capabilities can be restricted, so even if a user had the ACL  
credentials, they wouldn't be able to access the DB.

A capability layer enables all sorts of fine-grained scenarios, such  
as a programmer creating a program in the layer that has access to a  
few files or DB tables in the programmer's control, and publishing  
that program so others can use it --- the other people can grant the  
program access to one or more of their own files or resources.  The  
program itself will never be able to violate that sandbox: the worst  
it could do is mess up the few files it has been granted access.   
Again, we're assuming here the layer itself doesn't have bugs that  
would allow one to escape the capability security world, but again  
this same vulnerability exists in the top-to-bottom case.

>>>>
> Because adoption of technologies (especially in the security field,
> which is quite disfunctional in this respect) does not generally  
> proceed
> according to technical merit. Luck, and marketing, play huge roles,
> that have been systematically underestimated by capability advocates.
> There haven't been enough *fully* implemented capability systems
> for one to get lucky. A partially implemented system stands no chance.

A capability-secure layer is not "partially implemented" --- it's  
fully implemented at that layer, as is the case with any such system,  
no matter how top-to-bottom it is.  And, as I've noted before, it is  
already being used in Caja, which is already being used in production,  
and it is going to be used by at least two major projects which I've  
been involved with.  And the beauty of these systems is they fully  
interoperate with the existing ecosystem of software out there, while  
providing powerful capability security-based security management.  I  
believe the emphasis on top-to-bottom systems is the chief impediment  
to the adoption of capability security --- because it forces people to  
choose to throw out everything they're using now, which is simply  
untenable.  There is a way to introduce capability security to the  
wider world, and it doesn't require building top-to-bottom systems  
(though I agree that eventually, top-to-bottom is the wave of the  
future).

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