[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

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

I have to say that I find the implication that I'm maintaining this
position based on unwillingness to change it, to be rather irritating.
I'm maintaining it because it's a valid logical argument from premises
that I believe based on experience.

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

It's reasonable for you to say that you disagree with a premise
of the argument (although it would be useful in that case to
indicate which one), but it's simply not correct to say that the
argument doesn't make sense.

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

And what I'm saying is that I don't believe it is realistic to expect
such a layer to "nearly totally mask insecurity".

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

It had better not be chaotic, because chaotic behaviour in the underlying
physical machine is supposed to already have been abstracted away by the
digital logic layer (except with negligable failure probability). If it
hasn't been, then some lower layer has been very badly misdesigned.

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

You said that every approach to simplifying complexity involves
*writing* a layer. I repeat, that is not true.

>> 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 potential for programs behind the firewall to access the system
other than by its capability interface, is a hole in the sense I meant.

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

That helps, certainly, but the security is still dependent on 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.

Or, the system that has the capability layer can be accessed at its
ACL layer by one of the legacy systems behind the firewall, and that
legacy system can potentially be subverted by an attacker.

The point is, you can't analyse the system as a capability system
while its non-capability interfaces are being used (but if they are
not used, then their existance cannot be claimed as a compatibility
advantage).

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

Please don't misrepresent my argument. I was very clear that my
objection was that this approach is insufficient in the long term --
not that it is pointless, and not that it doesn't reduce short-term
risk.

-- 
David-Sarah Hopwood ⚥