[cap-talk] Capability levels - transparent network extension, no encryption

[Jed at Webstart]

At 02:51 PM 8/18/2006, Jed Donnelley wrote:
>At 05:46 PM 8/17/2006, Mark S. Miller wrote:
>>Jed at Webstart wrote:
>> >> Yes, if Alice, Bob, and Carol are mutually non-reliant machines
>> >> plugged in to the Internet, Alice cannot safely make assumptions
>> >> about who Bob cannot talk to. OTOH, within an object-capability
>> >> system, if Bob is an object instantiated by Alice, Alice can know
>> >> that Bob can talk to only those that Alice has enabled him to talk
>> >> to. This is the difference.
>> >
>> > I understand.  Now consider a situation where Bob is a process on
>> > a separate CCS on the other side of an "open" network, but where
>> > the two CCS systems communicate over an encrypted link (e.g. latest
>> > KGx) and then use something like the DCCS mechanism to distribute
>> > capabilities between the systems.  Under this scenario Alice creates a
>> > remote "Bob" and initializes it with the limited capabilities that Bob
>> > should have.  I.e. Bob is confined by the remote CCS system much
>> > like Bob could be confined locally.  In that case can one trust the
>> > confinement across the 'open' network?
>>
>>Can who trust...? I care about - can Alice trust...? Since, by assumption
>>(mutually non reliant machines), Alice does not trust the machine Bob is
>>running on, the answer is no. Alice cannot trust that Bob's 
>>platform (machine,
>>TCB, whatever) is playing by the rules. Therefore, she can't trust that Bob
>>doesn't have other access.

I think I see where my confusion is.  I think I misunderstood what 
you meant by "mutually non-reliant machines" plugged into the 
Internet - though in retrospect I think your wording is clear.  I was 
focusing on the network as the "non reliant" hardware that I was 
trying to extend over, but assuming that the machines at both ends 
(what I refer to as the CCSs) can be depended on.

However, tying this back to the source, this is the quote from your 
thesis that I was concerned with:
_______________________________________________________________
"11.5 The Limits of Decentralized Access Control

This dissertation mentions three forms of capability system: 
operating systems like DVH,
programming languages like the non-distributed subset of E, and 
cryptographic capability
protocols like Pluribus. The object-capability model we have 
presented applies only to the
first two: operating systems and programming languages. Our model 
implicitly assumes a
mutually relied upon platform, which is therefore a central point of 
failure. In the absence
of this assumption, we are left only with cryptographic enforcement 
mechanisms. Cryptog-
raphy by itself can only enforce weaker access control properties. In 
exchange, cryptography
enables us to build systems with no central points of failure."
_________________________________________________________________

Perhaps you can see where my confusion came from.  You say "Our model 
implicitly assumes a mutually relied upon platform [e.g. as you seem 
to suggest above the two CCS systems that mutually rely on each 
other], which is therefore a central point of failure."  Why is it 
that a "mutually relied upon platform" implies a single point of 
failure?  Remember our discussion about distributed hardware (no 
single point of failure) that can reliably process network addresses 
and how something like a DCCS can be build on such an infrastructure.

I wonder if I'm not somehow also misunderstanding the above.  The 
specific issue that I don't understand is how cryptographic systems 
can achieve any more fault tolerance than non cryptographic systems - 
or visa versa, how non-cryptographic system are necessarily less 
fault tolerant.  From my perspective (e.g. consider a "cryptographic 
system" like Amoeba or NLTSS vs. a non-cryptographic system like the 
DCCS) the fault tolerances issues are the same.  A failure in a 
component CCS takes down that part of the system and anything that 
depends on it, but not the whole distributed system.  Similarly a 
failure in a component of a cryptographic distributed capability 
system takes down anything that depends on that component and not the 
whole distributed system.  Can you clarify (perhaps only for me - 
apologies if so) what you mean in the above?  Does this issue come 
back to our discussion of an "open" (can't depend on network 
addresses) network vs. a network where network addresses can be 
trusted - but still with no central point of failure?

 From my perspective a transparent network extension of a CCS such as 
the DCCS could be implemented without cryptography (as was done in 
the DCCS paper) or with cryptography (e.g. as described in the 
Managing Domains paper - though in a strictly network context) and 
the fault tolerance would be the same.  You seem to suggest that such 
implementations must necessarily be different regarding single points 
of failure.  I'd like to understand why.  I hope we're not going in a 
loop here.

--Jed http://www.webstart.com/jed/