[e-lang] VatID + Swiss Number equiv. to Password Capability?

[Toby Murray]

Mark Miller wrote:

>At 05:47 PM 8/12/2004  Thursday, Toby Murray wrote:
>  
>
>>Therefore, the Monash system appears like it can enforce confinement in the 
>>face of covert channels. It can also enforce confinement, even if Bob can 
>>communicate via overt channels with another party (ie. even if Bob has a 
>>capability to say Dave, he still can't give Dave access to Carol). 
>>Therefore, it seems to provide stronger protection than a normal 
>>object-capability system since we don't need to limit those parties Bob can 
>>communicate with in order to prevent him passing on the caps we give him.
>>    
>>
>
>Are you speaking of confinement of permission or authority? 
>
Is there a difference? I didn't realise - can you explain?

>I don't see how 
>the Monash system can be *more* powerful than an object-cap system regarding 
>the ability to limit inappropriate propagation of authority. Am I confused? 
>Can you construct an illustrative example?
>
>  
>
Did you get my followup? I realised that it I was wrong -- it is not 
more powerful, since an object-cap system (eg. E) can still provide 
confinement even with covert channels as well. The Monash system does 
allow much easier revocation (just remove the cap record from the 
catalogue), and is easy to test for equality (same serial number and 
volume ID means same object being addressed).
The only thing about Monash that I see as a bit "non 
object-capability"-ish, is the association of a permission bitvector 
with caps in the catalogue. This makes some things easier, like 
delegating authority that is less than your own: eg. if Alice wants to 
allow Bob to access Carol's "read" operation, then she just derives a 
capability from her own (that presumably can access more than just 
"read") that only has the permissions necessary. She doesn't have to 
create a "proxy" type object that only exposes this operation. Since 
Monash derivative capabilities are destroyed withn the parent is 
destroyed, we get the same property that if Alice's access is revoked 
then so is bob's.
.This is good. But, conceptually a capability that is derived that has a 
zero permission bitvector associated with it appears to be able to 
address an object wihtout providing any authority, breaking one of the 
funcamental proeprties of object-capabilities. However, if the system 
prevents the creation of these, then I see that Monash provides the same 
benifits as any other object-cap system.

>>BTW the *-proeprty seems perfectly enforcable by this system, meaning that 
>>at least this password cap ssytem can enforce it.
>>
>>Of course the "lockword" scheme doesn't really appear like it would apply 
>>very well in a distributed environment, since there is no single trusted 
>>"system" that can enforce the lockwords etc.
>>    
>>
>
>Yes, that's the crucial issue as to why Monash is more like a partitioned 
>system, and less like an Amoeba-like system. Given that my xor worry is 
>groundless, the hidden per-subject lockword serves a function similar to the 
>traditional per-subject c-list.
>
>
>  
>


-- 
Toby Murray
Software Engineer
Advanced Computer Capabilities Unit
Information Networks Division
DSTO, Australia

IMPORTANT: This e-mail remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
Crimes Act 1914. If you have received this e-mail in error, you are
requested to contact the sender and delete the e-mail.