l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Distributed Capabilities


From: Eric Northup
Subject: Re: Distributed Capabilities
Date: Mon, 27 Mar 2006 10:53:04 -0500

On Mon, 2006-03-27 at 07:57, Ludovic Court?s wrote:
> Tom Bachmann <address@hidden> writes:
> > As described in one of my mails [1] to coyotos-dev and somewhere on
> > the E language homepage [2] it is possible to implement transparent
> > "remote" capabilities, i.e. caps that are invoked like normal local
> > ones but that actually invoke servers on other machines over the
> > net.
> 
> 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.  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.

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!

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.

-Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]