Re: Distributed Capabilities

[Ludovic Courtès]

Hello,

Eric Northup <address@hidden> writes:

> On Mon, 2006-03-27 at 07:57, Ludovic Court?s wrote:
>> That is feasible, except that you lose confinement (i.e., the bit
>> representation of capabilities is visible to the participants, so one
>> can transfer capabilities off-line, e.g., over the phone), unless you
>> consider that some ``trusted kernel'' hides that representation to
>> applications on both ends.  This is what is proposed in [0] where the
>> trusted thing is the language runtime running on both ends.
>
> 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.

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?

> 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?

> 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.

> 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.

Thanks,
Ludovic.