Re: Distributed Capabilities

[Eric Northup]

On Mon, 2006-03-27 at 12:25, Ludovic Court?s wrote:
> Eric Northup <address@hidden> writes:
> > On Mon, 2006-03-27 at 07:57, Ludovic Court?s wrote:
> > I don't entirely understand what you mean by "lose confinement".  If
> > you transmit a capability to a process which you don't know is confined,
> > then there is a possibility that that capability will get spread around
> > far and wide.  But you can still be *aware* that the recipient is
> > possibly unconfined.
> 
> I meant that participants in such a distributed system are unconfined
> ``by default''.  They have access to the representation of capabilities
> and may consequently spread them around without its originator knowing
> it, and nothing can be done against it.

But this is true even in the non-distributed case!  When transferring
capabilities, you always assume that the other party is unconfined until
you know otherwise.  And there are only certain situations where you can
actually get a guarantee of confinement.

> In E, the language runtime running at both ends enforces confinement of
> the programs it executes as I understand it.  Or rather: it is expected
> to do so.  Is this correct?

In E, a hostile remote Vat (instance of E) which receives a capability can
transmit it around to anyone and everyone.  But the hostile Vat, or other
computers which receive copies of the capability can't do any operations
which weren't actually authorized by that capability.  The hostile Vat is
*not* required to be running a correct version of E for this property to
hold.

> > If you look at the Constructor pattern, consider
> > whether it would claim that a network capability proxy (the thing which
> > can respond to remote invocations) is confined.
> 
> You are referring to EROS' constructors, right?  Sorry, I'm not very
> familiar with EROS' constructors.
> 
> I guess a network capability proxy would always claim that the proxied
> processes are unconfined.  Is it what you meant?

Exactly.

> > Also, when you say "the bit representation of capabilities is visible",
> > I agree in terms of being unable to prevent the transmitted capability
> > from being copied around everywhere.  But that isn't actually unique to
> > distributed capabilities - you can have the same problem locally!
> 
> How?  Suppose you copy a pointer to some data within a process' address
> space, or a file descriptor from a process' set of open file
> descriptors, to another process: that doesn't grant any access right to
> the recipient.
> 
> Similarly, if I understand correctly, in ``pure'', protected capability
> systems like EROS and Coyotos, capabilities cannot be transferred
> without support from the kernel.

Right.

But once you have transferred a capability to some program (local or remote,
it doesn't matter), that program can then give that capability out to 
anyone and everyone.

> 
> > E's CapTP ( http://www.erights.org/elib/distrib/captp/index.html )
> > provides the property that giving a capability to a hostile remote
> > system does not expose you to any additional vulnerability than it would
> > if you gave the same capability to a hostile local process.
> 
> Right, but I think this issue is separate from that of confinement.

I agree.  But I think you are over-estimating how often real confinement
happens -- just because you transfer a capability to a process on a
local machine running the same kernel-protected capability kernel, that
doesn't mean that it is confined.  The kernel-protected bits won't escape,
but there is nothing which prevents the recipient from acting as a network
capability proxy server, and allowing any computer on the internet to gain
full access to the authority from that capability.

Just protecting the bits of the capability isn't enough to protect the
authority conveyed by those bits.  So I think the question of "local or
remote?" is separate from the question of "confined or unconfined?".  The
way they are tangled up is that we can (using the KeyKOS/EROS constructor
mechanism, for example) sometimes answer confinement questions in the local
case.  For the remote case, answering confinement questions becomes much
harder, and probably requires introducing TPM-type hardware.

-Eric