[e-lang] VatID + Swiss Number equiv. to Password Capability?
toby.murray at dsto.defence.gov.au
Fri Aug 13 01:30:06 EDT 2004
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.
Advanced Computer Capabilities Unit
Information Networks Division
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.
More information about the e-lang