Split Capabilities: Making Capabilities Scale

Karp, Alan alan_karp@hp.com
Fri, 14 Jul 2000 09:42:27 -0700


> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Thursday, July 13, 2000 5:57 PM
> To: Karp, Alan; 'Norman Hardy'; e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > 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.
> 
> That is what I was getting at. I did not mean capability 
> expiration. As an
> example, consider the system library (.so) files. A 
> read-write capability is
> generated for each. Once a given library is written these 
> capabilities are
> never used again. It is surprising how many files in a system 
> are either
> "initialize once" or purely temporary and short-liveed.

Whether the capabilities are ever used again or not is application
dependent.  An application that knows the file will never be used again
should delete it.  E-speak encourages this behavior by charging the owner's
quota.

Even if the r/w capability is never used again, someone needs the "delete"
capability, or the file is unreachable.  E-speak Beta 2.2 recognized this
problem and was able to remove such resources (well, the repository entries
for them anyway) because the capabilities themselves are resources with
repository entries.  If capabilities cane seen hidden from the platform, as
with SPKI certificates in e-speak DR 3.0, you can never be sure that there
isn't an outstanding capability or that one won't be generated in the
future. 

> 
> > While I agree that least privilege should apply to every 
> single request,
> > market pressures forced us into a more conventional model 
> as the default.
> 
> Can you expand on this? Having never seen a capability 
> system, the market
> doesn't know what it wants in this area. I'm therefore 
> dubious about claims
> of market pressure. Sometimes the child shouldn't get the lollipop
> notwithstanding how hard they may cry about it.

The problem is related to the fact that e-speak capabilities and resource
handles are obtained independently and have no obvious relation to each
other.  Our first demonstrations had clients explicitly listing the access
rights they wanted on each request.  We were told in no uncertain terms that
requiring this level of detail from users would be unacceptable.  Perhaps,
if we'd focused on building tools to make it easier, ...

> 
> > We still provide a means to narrow access rights for those 
> knowledgeable
> to
> > understand why the effort is worthwhile.
> 
> You have now said words to this effect twice, and I find them 
> a source for
> concern. You are tacitly assuming that my unwise choices do not impact
> MarkM's ability to construct a secure environment. In 
> connected systems this
> is untrue, and it is therefore reasonable to set policy.

E-speak access control is based on a couple of principles.  First of all, I
don't give a hoot about your resources, and you shouldn't rely on my to
doing anything to protect them.  Secondly, if I whisper a secret to you, and
you blab it to the world, I'm out of luck.  No middleware in the world can
help.  I believe Mark would agree.

If you give me the right to do something, I may use that right improperly.
There's nothing you can do except not give me the right in the first place.
Set all the policies you want, but if you can't enforce them, what's the
point?  You might be able to detect policy violations and revoke my
privileges if I'm a bad boy, but it's not always easy to distinguish
violations from legitimate use.  Mark might say that he'll enforce the
policy in the language, but in a distributed system you only see the
messages.  I might be using my own language.

> 
> > > 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.
> 
> When the last client "forgets" that capability, it is dead 
> and all access
> lists associated with it can be killed. A new capability 
> conveying the same
> authority to the object may later be fabricated, but this has 
> no association
> with the old capability.

How can you know when the last reference was dropped in a distributed
system?  I know it's impossible with SPKI certificates as capabilities.
E-speak Beta 2.2 capabilities never leave the machine on which they were
created, and they have entries in the repository.  The engine then knows
when the capability has been destroyed and which resources use it to
determine access rights.  The question for e-speak Beta 2.2 is "When can I
delete the repository entry for a capability?"  If the answer depends on
reference counts, I think the question is unanswerable in a distributed
system.  In e-speak Beta 2.2, the decision depends only on local
information.

> 
> > Recall that a split capability is not associated with any particular
> object.
> 
> I think that answers my question.
> 

_________________________
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