Re: Amoeba's approach to capabilities

[Ludovic Courtès]

Hi Jonathan,

"Jonathan S. Shapiro" <address@hidden> writes:

> Capability systems can be divided broadly into two types: protected and
> unprotected.

[...]

> Unprotected capability systems include all systems where the capability
> is expressed as data. This is attractive because it simplifies the
> interprocess communication transport, but it is not securable for
> reasons I will discuss below.

I understand that having capabilities which are not representable as
bits (like references in Java, Scheme, etc.) is a very strong property.
In particular, transfer can only occur with the cooperation of the
trusted kernel, as you said.

Yet, practically, what impact does it have?  File descriptors, within a
Unix process, can be easily guessed for instance, because they are known
to be allocated incrementally starting from 3.  It would be harder if
they were randomly allocated.  Pointers to valid data within a 32-bit
address space are also not that easy to guess (provided one doesn't have
any knowledge of the underlying OS internals).  How about capabilities
on top of L4 X.2 containing one field which is the (globally unique)
thread ID of the server thread (the original proposal of Marcus)?

Also, the idea of being able to implement a capability system without
relying at all on a trusted kernel (i.e. real distributed capabilities)
is quite attracting.  But this comes at the cost of losing confinement,
indeed.  I'm starting to understand those ideas and tradeoffs.  ;-)

> There are two common methods for this
> partitioning:
>
> 1. Protection by encryption (as in SPKI/SDSI)
> 2. Protection by sparse allocation (as in Amoeba)
>
> Both approaches have the problem that a capability can be precompiled
> into the data space of the program in an undetectable way (e.g. by
> compressing the bits), and that capability transfer can be hidden in a
> similar fashion.

So this is the lack of confinement, right?

> Boebert's claim that "unmodified" capability systems cannot enforce the
> *-property is correct for unprotected capability systems.
>
> There are some further complications when one begins to think about
> distribution. The right way to think about this is that a distributed
> capability system is one in which the TCB has been distributed. Exposing
> the capability bits within the TCB (or within two collaborating TCBs) is
> not a problem. This implies that building an encrypted connection
> between two mutually trusting kernels doesn't violate my definition of
> "protected". The "protected" part only concerns interactions between
> applications and the TCB.

Right.  This corresponds to what's advocated in [0]: a distributed
protected capability system /can/ be implemented provided both machines
run a "trusted" language runtime that hides the network representation
of capabilities to the code that uses it.

> The random number is sparsely allocated from a large space.
>
> Andy (Tannenbaum) was a bit optimistic in his belief that this was good
> enough. Sparsity does not protect these capabilities at all, and cannot.

Well, it does not allow to control their transfer (no confinement).
Yet, they are hardly forgeable or guessable in actuality.

[...]

> What Andy failed to consider was the problem of hostile or collusive
> programs, such as:
>
>   1. Authorized program A intentionally hands a capability out to
>      someone who shouldn't have it, or

If we look at [1], A and "someone" are "not supposed to speak"; however,
due to the lack of confinement, A is able to pass a capability to
"someone", right?

>   2. Hostile developer D precompiles some capability bits into an
>      application so that they can leak information.
>
>      [By the way, this really happens! Eric Allman is known to have
>       installed a root backdoor into early versions of sendmail
>       for purposes of remote administration.]

I'm not sure I understand what you mean by "precompile".

Thanks for your explanations!

Ludovic.

[0] http://erights.org/elib/capability/dist-confine.html
[1] http://erights.org/elib/capability/delegations.html