[cap-talk] keyrings and bootstrapping capabilities

[Peter Amstutz]

On Thu, May 24, 2007 at 12:33:45PM -0400, Kevin Reid wrote:

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

How is it over-broad?  That is precisely what I am trying to avoid and 
why I'm looking for input from this list.  I understand that managing 
access to the "keyring" or other table of elevated capabilities is very 
sensitive, and presumably requires some kind of user agent that mediates 
access.  How has this been handled by other capability systems?
 
> > 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.

Fair enough.  I skimmed the Horton paper and it looked fairly similar to 
what I had in mind in terms of providing a way of asking the object in 
question to issue a new capability that provides an audit trail noting 
that the capability had been transferred to the 3rd party.  I'll read it 
over again in depth.  Since I'm designing this from scratch, I'd like to 
follow the best design patterns for capabilities, but I am also not 
restricted by the requirements of fitting anything into an existing 
security design.

I should mention one thing I'm trying to avoid (or finesse) is the 
notion of "facets", at least in the E sense.  My understanding is that 
in E, if you want to grant read-only access to something, you have to 
actually instantiate a new object that wraps the original object and 
acts as a gatekeeper and only permits read-only operations.  This is 
inconvenient for me for a couple of reasons, the first being that this 
is being implemented in C++, which is not known for being a dynamic 
language, so all possible policies need to be known at compile time.  
The second problem is that if security is enforced by possibly arbitrary 
code, reflection (knowing completely what you can and cannot do) is 
impossible, and saving objects to orthogonal persistance or doing 
replication is difficult due to lack of a completely declarative 
security model.  Thus, I envision a security policy (a facet) as being 
essentially a list flagging which methods are callable and which are 
not.

On a side note, do capabilities offer any insight into building systems 
that include resource limits or quotas?

-- 
[   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/24591de6/attachment.bin