Re: Amoeba's approach to capabilities

[Marcus Brinkmann]

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.

> Maybe the whole difference is here: I consider that "hard" means "next
> to impossible" (if you know that a given server implements an object on
> a given port, you still have to guess 80 bits, which is not something
> that can reasonably be performed by brute force), but you seem to
> believe that it's not that hard.  Is that correct?

Here is one problem you might think about.  I have a capability
handle.  Now I call my friend on the phone and tell him the handle.
He inserts the handle into his running program, and can access the
capability.

The problem is not really that he can access the capability.  As I was
cooperating with him, he could just as well have relayed his actions
through me.  The problem is that the capability could be copied
_outside_ of the system, defeating monitoring mechanisms.

This fails the control of transfer of access rights, and thus the
control of transfer of information, and makes endogenous verification
(proof from within the system that an object is not accessible from a
task) impossible.

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.

Thanks,
Marcus