Re: Amoeba's approach to capabilities

[Jonathan S. Shapiro]

On Fri, 2005-10-07 at 15:21 +0200, Marcus Brinkmann wrote:
> At Fri, 07 Oct 2005 14:02:43 +0200,
> address@hidden (Ludovic Courtès) wrote:
> > I think I understand what you mean.  The problem is that I don't
> > understand how it relates to Amoeba's capability implementation,
> > summarized like this:
> > 
> >      A capability typically consists of four fields as illustrated in Fig. 
> > 2.
> >   1. The put-port of the server that manages the object
> >   2. An object number meaningful only to the server managing the object
> >   3. A rights field, containing a 1 bit for each permitted operation
> >   4. A random number, for protecting each object
> > 
> > (1) is a globally-unique identifier returned by the kernel, (2) is
> > computed by the server managing the object, and (4) is computed using a
> > secret random number known only to the server (the random number itself
> > is not part of the capability, unlike one might think from the above
> > description).
> > 
> > How _this_ is protected by sparsity?  Perhaps this is just a matter of
> > vocabulary.  However, my understanding of this is that capabilities are
> > computed using information known only to the server implementing them,
> > which makes it "hard" to forge new capabilities.
> 
> I don't know Amoeba, and you didn't say what the _client_ gets to see
> as a capability handle.  I assume it contains some element, a hash or
> something, which was calculated from the random number.  Then this
> hash code (or whatever) essentially becomes the "new random number"
> which is protected by sparsity alone.

Amoeba does not use such a hash. The bit representation of the
capability is visible directly to the client. If the client wishes to
transfer that capability, it does so as a data item.

> Also, _if_ rights amplification is possible in the system, and the two
> users have each one part of a pair needed for rights amplification,
> they can amplify their rights while defeating monitoring mechanisms
> that may be in place to prevent such a thing from happening, or at
> least leave a track record of it.

If rights amplification is logically present in the system, you are
already screwed from the beginning. It has nothing to do with the
capability representation.

EROS, for example, implements a rights amplification operation, but it
could be removed without altering the expressive power of the system.
The actual operation that we have simply permits a large degree of
storage optimization. An amplifying operation that satisfies this sort
of design rule doesn't *logically* amplify any rights, so the rule above
should be read as a logical restriction rather than a blind restriction
on rights amplification as a mechanism.

shap