Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Saturday, July 08, 2000 5:39 PM
> To: Karp, Alan; 'Norman Hardy'; e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > We have a
> > counter example to the statement that most capabilities 
> never need to be
> > created.  Our e-speak Virtual File System must issue 
> capabilities for each
> > access right of each file it controls.  (Here's where 
> wildcards are used.)
> > While any client over any session may need only a few 
> capabilities, over
> > time a substantial fraction of the possibilities will end up being
> created,
> > and each client may end up holding a substantial fraction of them
> 
> I suspect that what really happens is that over time, nearly every
> capability will be generated and used for a brief period of 
> time and then
> permanently retired, never to be accessed again. In your 
> design, I do not
> see that it is easy to retire the access lists when all processes have
> dropped their respective capabilities. This seems a potential 
> source of
> security issues.

I don't understand the term "permanently retired" in the context of
persistent objects, such as files.  "Permanently retired" implies that the
capability will never be needed again at any time in the future.  E-speak
can identify unreachable resources and "permanently retire" them.  I expect
you mean that the particular capability expires and a new one issued should
the need arise in the future.

> 
> I'm also struck by your comment that clients may hold a 
> substantial fraction
> of capabilities. Is this is a carryover from the Brevix 
> internals? In any
> case, the violation of "least privilege" embedded in your statement is
> self-evident, and to me that is a serious concern.

Although I personally liked the Brevix work, it had no influence on e-speak.
While I agree that least privilege should apply to every single request,
market pressures forced us into a more conventional model as the default.
We still provide a means to narrow access rights for those knowledgeable to
understand why the effort is worthwhile.

> 
> How do you ensure that when a capability is no longer needed 
> it is dropped?

How do you know that a capability will never be needed again in the future.
Recall that a split capability is not associated with any particular object.

> 
> 
> Jonathan
> 

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278