[cap-talk] keyrings and bootstrapping capabilities

[Kevin Reid]

On May 24, 2007, at 11:53, Peter Amstutz wrote:

> 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?

Bob asks for (or already has, in a suitable table) each of his RW  
files' read-only facets (or no-authority identifying facets if they  
have them), and checks for equality to those of the files in the  
directory Alice provided to Bob.

> 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 user name and password (or just a password!) constitute access to  
the user's "home directory" of capabilities, from which he (his  
software) can look up his own access to the file given its "public  
identifier".

> 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.

I think this is essentially the same as what I described above, but  
the way you say it makes me think of ambient authority and/or over- 
broad use of rights amplification.

> 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.

Such management need not be built into the core of the capability  
system - it need not know anything about user IDs. Take a look at the  
Horton system discussed recently.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>