[cap-talk] keyrings and bootstrapping capabilities

[Kevin Reid]

On May 24, 2007, at 13:31, Peter Amstutz wrote:
> 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.

It's not technically different; I was just worried by the way you  
described it.

In particular, such amplification should *only* be used in situations  
where the user can understand what's happening. Using it in other  
situations leads to the user-and-his-software becoming a Confused  
Deputy, accessing things the user had access to *for a different  
purpose*.

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

Facets can also be part of the original system. For example, in E you  
can write <file:foo>.readOnly() which provides a read-only facet.

I have heard that some capability operating systems represent  
capabilities as (implementation, access bitfield), where the bits are  
provided to the implementation to indicate whether this invocation  
should, say, allow write access.

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

What kind of policy do you imagine being defined at run time? I doubt  
that message-restricting facets will be; runtime behavior is more  
about *which object* is provided in some position than *how  
restricted* that object is.

> Thus, I envision a security policy (a facet) as being essentially a  
> list flagging which methods are callable and which are not.

There is another sort of facet: that which adapts the underlying  
object to another interface, and also forms an authority restriction  
because the new interface doesn't include the undesired operations.

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

Look at capability operating systems. EROS/CapROS and KeyKOS both  
have systems for providing limited CPU time and memory access.

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