Re: Amoeba's approach to capabilities

[Ludovic Courtès]

Hi,

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

> Calling these numbers "file descriptors" was a very bad choice of UNIX
> terminology. It is the file table entries that are the true descriptors.

[...]

I agree.

> One qualifier to this statement: guessing the names is harmless
> *provided* we are using private name spaces. (In L4sec speak: "local
> names"). If we are using a globally shared namespace, then the ability
> to guess names provides a channel for communication. This is because you
> can detect names that I have bound, and the presence or absence of a
> binding can be used to signal a 0 or 1. The resulting channel is
> actually a very high bandwidth channel. Thus: local name spaces are a
> foundational idea in secure systems.

Right.

> Yes you would lose confinement, but there is no possibility of
> implementing a capability system without a trusted kernel (or runtime).
> *Something* has to provide basic isolation enforcement. If you don't
> have this, then you cannot protect the cryptography, and if you can't
> protect that you have no protection at all in the kind of system you are
> contemplating.

Ok.  This is not a problem for an OS or language run-time.  However,
this means that collaboration in a fully decentralized way (various
machines on the Internet) cannot rely on a protected capability system.
Unless a "trusted kernel" is distributed among the participants, for
instance in the form of "trusted hardware" (which is IMO an oxymoron,
but that's another story).

It is quite ironic that the very mechanism that allows collaboration
among programs with no prior trust relationship requires the use of a
"single point of trust" (the "trusted kernel").  But as you said, it
looks inevitable.  That's a bootstrap problem: at the beginning, there
has to be some amount of trust.

[...]

> Actually, they are pretty well guessable
>
> More importantly, the inability to restrict their transfer is not a
> little thing. It's more of a "this architecture is completely and
> unfixably broken" sort of a problem.

Sure.

>> 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?
>
> I can't answer that, because I do not see any reference on that page to
> "A", and the phrase "are not supposed to speak" does not appear. Can you
> clarify the question?

Sorry for being unclear.  In
http://erights.org/elib/capability/delegations.html , I was actually
referring to the phrase "Are Bob and Mallet supposed to be able to
communicate?".  "A" and "someone" were used in your example:

   1. Authorized program A intentionally hands a capability out to
      someone who shouldn't have it, or

But I think I understood what you meant.  ;-)

Again, thanks for your clarifications,
Ludovic.