[cap-talk] - Karp - Capabilities - tracking responsibility (Was: Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson))

Karp, Alan H alan.karp at hp.com
Wed Nov 29 10:56:07 CST 2006


Jed wrote:
> 
> When the capability is accessed I want to know that it was 
> the capability
> that Tyler delegated to Bob and that the responsibility lies with Bob
> as opposed to with Tyler.  For this to work it doesn't 
> suffice for Tyler to
> create a revocable capability - even one labeled as being for 
> Bob - that he
> then sends (by whatever means) to Bob.  The communication must be
> such that Bob receives a capability that Tyler never had or 
> was able to
> access.
> 
I am assuming that when Tyler uses the capability it is over a channel
to Jed authenticated as Tyler.  Bob uses the capability over a channel
authenticated as Bob.  Since Tyler can't set up a channel to Jed
pretending to be Bob, there is no way Tyler can blame Bob for Tyler's
actions.  (We really need to switch to Alice and Bob so we can use
gender specific pronouns.)  Of course, that presumes that Jed has some
means of identifying Bob that is independent of Tyler.
> 
> >You can make capabilities separately revocable by 
> associating a "Do Not
> >Honor" list with each channel authentication.  You can get a 
> delegation
> >trail by a mechanism such as the one you built for Managing Domains.
> >Namely, associate a c-list with each channel authentication 
> and record
> >which channel the delegation request came from.  None of 
> these require
> >any changes by the capability creator or user, although the last does
> >require an additional step to delegate.
> 
> I'm sorry, but I don't follow you in the above Alan.  Perhaps you (or
> somebody else if I'm just being dense) could explain the above in a
> bit more detail including the notions in my further explanation above.
> 
Every system I know of uses a messaging layer that takes messages from
the network and forwards them to local recipients.  That layer typically
keeps a table that maps over-the-wire-capabilities to local references.
E keeps one such table per vat.  Client Utility kept one per channel.
If you keep one per channel, it's easy to keep a list of capabilities
that are valid for that channel or that have been revoked for that
channel.  

If you want to track delegations, then keep a mapping per channel.  If
Tyler wants to delegate a capability to Bob, Tyler asks Jed to make an
entry in the table used for channels authenticated as Bob.  Client
Utility used this kind of explicit introduction, and I believe you (Jed)
used a similar scheme in one of your systems.  Jed can record this
request in the mapping table.  Tyler can then pass the capability to
Bob.  Tyler can revoke Bob's use of the capability by telling Jed to
remove the entry.

_________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories 
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp/
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 423 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20061129/d0e4b6e6/attachment.vcf 


More information about the cap-talk mailing list