[cap-talk] What sustained interest in capabilities

[David-Sarah Hopwood]

Mitsu Hadeishi wrote:
> On Jan 8, 2009, at 12:28 AM, David-Sarah Hopwood wrote:
>>> You can analyze it as a capability system with the caveat that you're
>>> analyzing it with the assumption that an attacker has not compromised
>>> the layer.
>>
>> No, that is wrong.
>>
>> If anyone is using the system by a non-capability interface, even if
>> they are not an attacker, then the system is not a capability system
>> and cannot be analysed as one.
> 
> Again, by this logic, no system can be analyzed as a capability  
> system, because there is always the possibility of someone violating  
> the capability interfaces. For example, suppose someone were to  
> physically invade a datacenter and directly compromise the operation  
> of the physical CPUs; since such an operation is allowed by the laws  
> of physics, by your reasoning, it would mean one could not think about  
> the system in capability terms.

I'm afraid you haven't paid close enough attention to my argument.

If anyone is *actually* using a system by a non-capability interface,
then that system cannot be analysed as a capability system.

So, if someone in fact physically invades a datacenter and directly
compromises the operation of a physical CPU that was running a
capability system, then that system can no longer be analysed as
a capability system.

Analysing a system under the assumption that direct tampering with
a CPU does not happen, OTOH, is perfectly valid to the extent that
the assumption is realistic.

The context of my original objection was the case of one or more
legacy clients actually using your layered system by a non-capability
interface. Therefore, the layered system cannot be analysed as a
(pure) capability system. It doesn't matter whether the client(s)
are attackers.

> Or, to take the example of Joe-E, or Caja, you could also say these  
> cannot be analyzed as capability systems because they are currently  
> implemented on top of a legacy operating systems, browsers, etc.

Analysing them as capability systems is problematic, not as a matter
of principle, but simply because they depend on so much Java library
code that is not verified by Joe-E, or JavaScript/XUL/DOM code
that is not rewritten by Caja. That is, the implementations of Joe-E
and Caja both rely on TCBs that are far too large by any reasonable
standard.

You can assume that all of this code is harmless, but that's probably
a wildly unrealistic assumption. During the Caja security review, we
were all particularly impressed by the ingenuity, if that's the word,
of browser vendors in thinking up spectacularly badly designed and
difficult-to-hide proprietary extensions that are inconsistent with
capability security.

As language *specifications*, Joe-E and Cajita appear to be
capability-secure (although I would prefer them to be defined more
formally). The problem is that I think it is unreasonable to assume
that their existing implementations are correct and secure
implementations of those specifications. That's why the capability
community really needs to do more work on language implementation
from scratch with high standards of security assurance, IMHO.

Note that an insecure implementation of a security-enforcing language
can still be useful, in the short term. It at least allows you to
write and test applications for that language. In the case of Cajita
and Valija, it is also acting as a design influence on proposals for
"Secure ECMAScript", which would be implemented directly in browsers.

> Of course these systems can be analyzed as capability systems, within  
> the subset of operations allowed by the layer.  One can think about  
> intrusions by other systems as a separate case.

There's little point in assuming that something cannot happen, if it
actually can.

[...]
>> That is, I think that avoiding top-to-bottom systems due to a belief
>> that such systems are necessarily "unable to gain traction" is  
>> learning the wrong lesson from history.
> 
> I certainly defer to your superior knowledge of the history of  
> capability security.  However, to reiterate my argument, the simple  
> notion I am advocating is that web service architecture creates the  
> opportunity to implement a layer at the web interface level which is  
> capability secure.  This requires less buy-in and infrastructure  
> change than, for example, implementing everything in, say, Joe-E (much  
> as I like Joe-E).  One can implement the layer in Java, and thereby  
> take advantage of Java libraries, etc., while the code running outside  
> the layer cannot directly access that level.

I think you're overestimating the cost and underestimating the advantages
of implementing such a layer in Joe-E (for example). Taming Java libraries
is quite straightforward.

-- 
David-Sarah Hopwood ⚥