On Mon, 2006-03-27 at 12:25, Ludovic Court?s wrote: > Eric Northup <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
