[cap-talk] What sustained interest in capabilities

[Mitsu Hadeishi]

On Jan 8, 2009, at 1:55 AM, David-Sarah Hopwood wrote:

> Mitsu Hadeishi wrote:
>> On Jan 8, 2009, at 12:28 AM, David-Sarah Hopwood wrote:
>
> 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 I understand your argument, but it simply makes no sense  
whatsoever to distinguish the design I'm advocating and Caja or Joe- 
E.  They're precisely the same --- the legacy systems in the case I'm  
referring to are simply implementations, one can think of them as just  
libraries of code that may or may not be reliable.

A simple example of this might be an email capability.  You have an  
email capability that allows the holder to send email.  The underlying  
implementation is, say, some legacy Java library that actually sends  
the email.  From the point of view of the capability layer, however,  
it is an object capability, and there's no way to breach this and  
somehow gain access to the ability to send email indirectly, unless  
there's a severe bug in the underlying implementation or in one of the  
libraries.  This is precisely the same case as with Caja, Cajita, Joe- 
E, or any other capability language.

There are no "legacy clients" using the system via a non-capability  
interface; except insofar as there may be software or libraries  
involved inside the firewall that utilize the legacy interfaces.   
That's no different from legacy Java code calling other legacy Java  
code inside a library referenced by Joe-E.

I can only surmise from your objections that you are misunderstanding  
the nature of the design I am advocating.

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

Sure, there's a point, if the possible breach is exceptionally  
unlikely (as would be the case with the physical breach of datacenter  
security).  You can reason in the following fashion: "provided a  
breach does not occur..."  That's perfectly ordinary logic.

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

Perhaps you are correct, but if you think taming Java libraries is  
straightforward then you ought to see that the approach I am referring  
to is quite similar.

Mitsu