[cap-talk] keyrings and bootstrapping capabilities

[Norman Hardy]

On 2007 May 24, at 8:53 AM, 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?

I presume that the directory is a directory of capabilities, and by  
hypotheses here--capabilities to files.
I further assume that Alice and Bob look by having different  
capabilities to D.
In Keykos the directory has no concept of principal and Bob, using  
the capability D from Alice, can only read the files with the file  
capabilities he gets via D.

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

I take it that write access to the file is somehow protected by an  
RSA key.
This is not a capability paradigm but it has its uses.
In Keykos when one logs in one is attached to his own persistent  
instance of a shell which holds a capability to his own personal  
directory in which one can store secret keys.
I assume that a RW capability to the file's guard is in a widely held  
directory.
Presenting the secret key to the guard would do the trick.
The secret key need not travel to and from the public terminal.
Public terminals are, of course, still a problem!

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

You have described what we called a 'directory' in keykos.
It holds capabilities. About the only program with a key to the  
directory is the shell.
We have not found a need for the shell to 'find the best capability';  
indeed that sounds like an invitation to confused deputy problems.
If one is unclear why he should be able to do something it is best to  
first become clear rather that for some program to try to find an  
excuse why this user should be able to 'write on the file'.
Just because that is what the Unix kernel does, does not mean it is  
convenient, merely conventional.

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

Yes!

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

The Keykos practice was to zap the password that granted the person  
access to his persistent shell.
This is more and less than what you suggest and there are arguments  
for both sorts of severance.
If you discover that he has had motivation, means and character to  
subvert the system then killing his password access may not suffice.
To anticipate that unfortunate case it would be necessary to  
initially put his shell in a membrane.
Then actions by his remaining agents subsequent to his removal are  
blocked as well.
If he has contributed to mission critical function then you may well  
be out of luck.
If he has written and delivered code that you depend on with moles in  
it, you have problems whether or not the code was delivered within  
the system or not.

>
> 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 :-)

I think you must also attend to the confused deputy issue mentioned  
above.
This will require the user to sometimes rephrase a command so as to  
manifest the authority under which he acts.
We never found this a burden, but the user will know that it isn't Unix.

> -- 
> [   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 ]
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk