[cap-talk] keyrings and bootstrapping capabilities

[Peter Amstutz]

As part of the system I'm designing that I discussed the previous 
thread, I've been mulling over the bootstrapping problem for a 
capability system.  In particular, I see two challenges:

a) Alice and Bob are looking at directory D.  Alice has read-only access 
to the directory and all its contents.  Bob has read-only access to the 
directory (cannot add or delete files), but read-write access to certain 
specific files.  If Alice shares her read-only reference to the 
directory with Bob, how does Bob determine which files he can write to?

b) A user sits down at a public terminal and wants to log in to a remote 
system and edit a file for which he knows a public identifier, but 
doesn't happen to have the 128 bit capability key granting write access 
on hand.  The user should be able to log in with a user name and 
password and then be able to go on to acquire the capability to permit 
editing the file.

The best solution I have been able to come up with seems to provide the 
user a "keyring" of capabilities.  When some code acting on behalf of 
the user requires higher access than is available from the reference it 
currently holds, it would look up the object identifier in the keyring 
to get the best capability for that object that has been granted to that 
user.  Access to the keyring would be carefully controlled, of course, 
and by ensuring that untrusted code is never granted access to the 
keyring, you can still delegate authority without giving away the keys 
to the city.

Accomdating groups in this scheme is trivial, as a "group" simply 
becomes a keyring shared between multiple users.

In following with the c-list implementation I described previously, each 
capability key that is distributed would be logged with a user id.  
Revoking a user's access to part or all of the system would be a matter 
of revoking the capabilities granted to that user.

This may be the conventional solution -- I'm not sure, the E-Rights page 
is heavy on theory and abstract transactions, and light on design 
patterns in practice.

Are there any particular holes in this approach, and if so, are there 
alternate preferred ways of designing a capability system that address 
a) and b) above?  I think capabilities are the right underlying tool, 
but the user experience needs to be more or less the same as how people 
interact with computer security now (minus the security breaches, 
spyware, viruses etc :-)

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070524/32d15db1/attachment.bin