Re: Distributed Capabilities

[Ludovic Courtès]

Hi,

Eric Northup <address@hidden> writes:

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

What you are saying is that capabilities can be passed from process to
process (regardless of whether we're considering a distributed scenario
or not), which is true of course.  I agree that for this property to
hold, the runtime running on both ends doesn't need to be correct.

I was just trying to say that in the distributed case one cannot be
guaranteed that some remote process is confined, unless you assume some
trusted kernel running on both ends, like a *certified* E runtime
environment.

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

Exactly, or a certified language runtime.

You might be right in that I'm over-estimating when real confinement
happens.  Nevertheless, I consider confinement a very strong property,
hence being unable to implement it at all in the distributed case
(unless some trusted thing is relied on) seemed like a significant
difference to me.

Thanks,
Ludovic.