[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

On Jan 7, 2009, at 12:18 AM, David-Sarah Hopwood wrote:

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

The fact that you've been thinking about it for a long time can be  
both an advantage and a disadvantage.

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

Your argument doesn't make sense for the reasons I've already  
outlined.  If a layer is sufficiently well-designed it can either  
mostly or nearly totally mask insecurity or lack of order at the  
underlying layer (see below).

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

This is incorrect for fundamental reasons.  The layer itself can  
provide the order needed.  A von Neumann machine is essentially  
precisely that, as you should realize.  That's the whole point of a  
von Neumann machine: to provide a relatively predictable layer on top  
of a chaotic quantum world, to allow deterministic computation to  
proceed with a reasonable degree of confidence.

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

There are no complexity problems, and virtually no security problems,  
because the ACL is wrapped by a capability which is simply an object  
with ACL credentials.  These objects are entirely encapsulated.  Yes,  
a given capability runs as a single principal, so you're correct  
there, but I'm really not sure how else one would implement this in  
practice.  Of course you're right that somehow bleeding the capability  
world into the ACL layer would add untenable complexity, but that's  
not what we're proposing here, and it would of course totally violate  
the principle that the capability layer be pure capabilities from the  
point of view of the layer.

There are no "performance" problems, whatsoever, why would there be?   
We're talking about a simple object wrapper, which adds virtually no  
overhead. You're making a lot of assertions without any basis nor any  
explanation of what you're referring to.

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

You're missing the point I am trying to make.  Modifying a layer to be  
more secure is the same thing --- there's still an underlying layer.   
The underlying layer may just be the von Neumann machine but even THAT  
is a layer on top of the chaotic quantum foam that is our reality.   
There is always a layer in the design somewhere.  That's how all  
computational security as well as computational reliability is arrived  
at, for fundamental reasons (theory of computation).

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

My point is that there is a cost/benefit analysis to be made.  A  
capability layer can get you very far indeed.

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

You keep making assertions that have no basis in fact.  There are no  
"holes" poked in any of the designs I'm referring to, and I see no  
reason whatsoever why these "holes" would be either necessary nor  
useful.

The ACL layers are intended to be accessible behind the layer, as I've  
been saying all along.
>
> 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.

Okay, I misunderstood you.  However, as I'm trying to explain, we HAVE  
implemented a capability security design which is in fact operational  
today.  It's quite practically usable.  Fully functional, and intended  
to be deployed widely this year.

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

The approach I'm advocating a number of other folks on this list have  
already admitted is a useful approach being used by other teams as  
well.  So I guess we'll simply have to agree to disagree.

> That wasn't the critique. The argument was that the underlying layer
> was likely to be too complex and to introduce security weaknesses, if
> it is based on ACLs.

See above for my comments on this.  I have no idea what you're  
referring to; it doesn't describe the concrete design we came up with.

> That is *precisely* the kind of thinking that leads to security flaws.
> To paraphrase:
>
> "No other program can bypass the capability layer. Oh, except when
>  the program is behind the firewall, but that doesn't count."
>
> A program "behind the firewall" might be any random email virus. This
> makes the security entirely dependent on the firewall, which clearly
> can't be an effective long-term solution. Basing access checks on
> location of the requestor within a network creates unavoidable
> security weaknesses.
>
> Even if it is not practical to change all systems behind an existing
> firewall boundary to capability systems, it may be possible to do that
> for the most critical systems. If those were top-to-bottom systems,  
> then
> breaching the firewall would not by itself help an attacker to break
> those systems, because the attacker would have no authority to access
> them.

Yes, that is correct, however you're thinking about a completely  
different set of risks and level of probability of risks.  We're not  
talking about a corporate intranet with thousands of users behind a  
firewall.  We're talking about an SaaS system with NO humans directly  
using machines behind the firewall.  Yes, there's a potential security  
hole in that, obviously, to install or update the software a human has  
to access the software and upload stuff that could potentially have a  
virus in it; but we're not trying to solve that problem.  We're trying  
to solve the problem of security risks for people using the SaaS  
system via the capability security layer.  There are huge classes of  
risks that are eliminated by implementing a cap security layer (I  
won't go into these here but I can talk about them at another time).

In other words, what I am saying is that using capability security  
today, now, can be done in practical, usable systems which allows a  
huge class of risks to be eliminated.  The point is this is *extremely  
useful*.  It is not that it completely eliminates all risk.  Your  
argument seems to be that our approach is pointless because there's  
still a tiny risk that a virus could get in behind the firewall and  
thus go wild in the ACL-world underneath.  Yes, that is always  
possible, but that doesn't change the fact that even if that weren't  
the case, having an ACL-based interface to the system would introduce  
a huge class of risks that are eliminated by capability security.

Mitsu