[cap-talk] I Recant

Mark S. Miller markm at cs.jhu.edu
Tue Jan 16 10:22:15 CST 2007


Jonathan S. Shapiro wrote:
> On Tue, 2007-01-16 at 05:57 +0100, Pierre THIERRY wrote:
>> Scribit Jonathan S. Shapiro dies 15/01/2007 hora 19:47:
>>>   The test of an object-capability system is whether (1) the
>>>   capability/data partition is enforced by the system's run-time, and
>>>   (2) capabilities are explicitly designated when invoked.
>> I don't understand: how would any distributed system fulfill this
>> requirement: any hostile agent can decide to use caps as data, can't it?
> 
> The distributed system forms a distributed run-time. Communications
> between nodes need to be protected (for now: cryptographically). In the
> limit, a strong claim requires mutually trusted attestation.


What does the qualifier "In the limit" mean here?

It seems to me there's a simple dichotomy between two kinds of reliance 
assumptions regarding each node's platform (runtime, TCB, kernel), when 
describing the level of abstraction which includes each node's remoting system 
(capability protocol handler) in that node's platform.

* Each node's local platform does not rely on the correctness of the other 
nodes' platforms. Each node's remoting system uses cryptography to defend, not 
only against malicious behavior by the routing network, but also against 
misbehavior by the nodes at the endpoints. In this scenario, attestation is 
mostly irrelevant, and the limitations on confinement, etc, in my section 11.5 
apply. This corresponds to standard crypto assumptions, which I've described 
as "mutually defensive machines on open networks with no central points of 
failure".

* Each node's local platform is mutually reliant with the platforms of all the 
other nodes it remotes to. Under reasonable threat models, this assumption 
does indeed require "mutually trusted attestation", in which case my 
description of DCCS applies:

> [Given the assumption of mutually reliant platforms] From a
> security perspective, a DCCS "network" isn't distributed. It's a
> single multiprocessor CCS computer spread out over space by using a
> very long backplane.

Under such mutually reliance assumptions, object-capabilities are trivially 
possible, and none of the limitations of 11.5 apply. Each node's platform is a 
central point of failure for everything in the system as a whole, as these 
platforms together jointly form the shared platform (TCB, etc) for this system.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM


More information about the cap-talk mailing list