[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

Mitsu Hadeishi wrote:
> 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.

My view is based on experience in attacking layered systems. It is always
easiest to attack the weakest sublayer, and that is in practice *too* easy
in most systems.

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

I've been thinking about it for 15 years, so I think that counts :-)

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

That's true, and by "top-to-bottom", I mean to include the hardware --
specifically, that the entire system including hardware should be formally
verified to implement a computation model that is consistent with the
object-capability model.

Note that the verification can proceed one layer at a time. However, when
verifying layer n, the subset of the interface of layer n-1 that is used
by layer n, needs to be simple enough that it can be accurately modelled
and reliably implemented.

Current interfaces to hardware are too complicated to implement correctly
with high confidence (or at all). To see that this is true, just look at
the errata for current Intel and AMD processors.

[...]
> All security approaches, whether capability-based or ACL-based, are  
> implemented at some layer of abstraction above another, chaotic, and  
> highly insecure layer.

It can be insecure, but it had better not be chaotic.

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

It's not arbitrary, because the ACL system will enforce undesirable
security restrictions, and may impose unacceptable performance and
complexity penalties.

The security restrictions can sometimes be worked around by running all
code as the same principal. The performance and complexity problems may
be more difficult to avoid.

> So I agree the enemy of security is complexity, but *every* approach  
> to simplifying that complexity involves writing a layer of some kind.

That is not true. It is also possible to directly remove complexity
from the layer(s) that are too complex. This will often be at the
expense of compatibility, but not necessarily: it may be possible to
provide an emulation of the previous API that is only relied on by
'old' software and that is not in the TCB.

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

I never said that you could. The purpose of a top-to-bottom capability
design is to minimize risk, not to eliminate it.

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

Either the design intent is for it to be impossible to access the ACL
layer, or not.

If it is intended to be impossible to access the ACL layer, then
 - no greater compatibility or interoperability with existing
   software can be claimed;
 - the system is likely to have lower performance and higher complexity
   than an equivalent pure capability design.

If the ACL layer is still intended to be accessible other than via
the capability interface, then your argument is simply incorrect: the
system does not behave like a top-to-bottom capability system and
cannot be accurately modelled as such.

In practice what tends to happen is that holes are poked in the
capability layer in order for existing software to work. In fact
I've never seen an example that didn't end up with holes, and with
resulting security flaws. That is why I've changed my opinion towards
being highly skeptical of non-top-to-bottom capability systems.

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

You've misunderstood my argument; perhaps I wasn't clear enough.

Most capability system designs have not been fully implemented, in the
sense of being practically usable, even as a single layer.

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

A top-to-bottom capability system would also fully interoperate with
other systems -- using standardized protocols and file formats.

If you mean that it is necessary to support existing operating system
ABIs, then I don't agree. It is sufficient to be source-compatible and
protocol-compatible.

-- 
David-Sarah Hopwood ⚥