Split Capabilities: Making Capabilities Scale

[Jonathan S. Shapiro]

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?
2. Can the user present arbitraty bits in such a way that they will be
interpreted as a capability?

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

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

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

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



shap