Split Capabilities: Making Capabilities Scale

[Karp, Alan]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Monday, July 24, 2000 8:34 PM
> To: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> Some quibbles with the summary. None change your conclusions.
> 
> ----- Original Message -----
> 
> > The internal state of a capability may be accessible to a 
> user, in which
> > case this state must be protected cryptographically.  If 
> the state of the
> > capability is kept in the platform, such protection is not needed.
> 
> There are two issues here:
> 
> 1. Can the capability representation be examined by a user?

Crypto is needed if the user can change the representation.  I see no
problem with the user examining the representation except that it violates
the principle of "least information".

> 2. Can the user present arbitraty bits in such a way that they will be
> interpreted as a capability?

Crypto (in the sense of protecting the capability, not the link) is needed
if the answer is yes.  In e-speak 2.2, we had no API by which a user could
present a repository handle to the engine.  That decision meant that we
didn't have to worry about knowledge of repository handles leaking out of
the engine address space.  This feature is equivalent to saying that the
user can only present a handle to the capability, not the bits of the
capability itself.  In e-speak DR 3.0, users can present arbitrary bits as a
capability, so crypto is needed to make forging capabilities difficult.

> 
> The first presents a problem of encapsulation. The second 
> presents a problem
> of detectability, and therefore of security.

I don't understand why it's a problem of encapsulation.  Do you mean what I
call "least information"?

> 
> > A CC may be obtained independently from the process of obtaining the
> handle.
> 
> I agree that the two can in principle be separated. In the 
> conventional
> capability model they *aren't* separated.

Agreed.  I don't recall any of the examples in Levy's book separating them.
E-speak DR 3.0 does separate them this way, and I seem to remember another
(non OS) system with cryptographically secure capabilities doing the same.

> 
> > The access rights can be represented as an interface representing a
> thinning
> > of the full interface of the object.
> 
> I have said this, and I believe that in all of the capability-based
> operating systems either (a) this is true, or (b) we can 
> synthesize a "top"
> for the CPO such that this is true in essence. I have come to question
> whether this is a definitive property of capabilities, per my 
> earlier mail
> about the distinction between OO and capability-based systems.

Notice that I said "can be represented", not "are represented".  It is easy
to envision a data dependent capability.  For example, a capability could
grant me the privilege of writing a check up to $100 but not over when the
account balance is under $500.  While such a rule could be represented by a
different method for each case, the system would get pretty complex should
there be a number of such rules.  On the other hand, I believe it is
possible to reason about the system as if every capability is a thinning of
some theoretical interface.

> 
> > Revocation can be enforced by issuing a CC for a proxy 
> object.  Destroying
> > the proxy revokes the capability.
> 
> Quibble: you only need this for *selective* revocation.
> 

Correct unless the object has state that I want to preserve while waiting
for a new capabilty to be issued.  For example, anyone can access the object
while the auditor is up.  When the auditor goes down, I want to revoke
everyone's privlege, but I don't want to destroy the object because I would
lose its state.

> 
> 
> shap
> 

_________________________
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