Hi, On Thu, Jun 11, 2009 at 07:07:35PM +0200, Carl Fredrik Hammar wrote:
> To load a mobile object we first need to load its code base that has > been specified by the sender of the object. The ideal way to do this > would be to send a port to a .so file and then load that. > > If we loaded the code module unconditionally, the sender could > essentially inject arbitrary code in the receiver. So we need to > determine who has control of the module and only load it if it is a > trusted user, e.g. the same user or the root user. > > But the FS interface does not provide any means to do this that isn't > easily faked. Checking who the owner of the file is just gives you a > UID which is just a plain integer. Any FS correctly implementing the protocol will ensure that only a user actually having the matching ID capability has control over the file... > And there doesn't seem to be anyway to check who controls the actual > translator either. If that is the case, there is indeed no hope of using the file system to derive trust. > It hit me that what we want is essentially reverse authentication. > That is, letting the sender authenticate against the receiver, which > would normally be the server and the client respectively. After this > the receiver will know for sure who controls the module. I'm confused now. The way I read this, it sounds just like what I have been suggesting all along: Trust the code if we trust the sender... > Of course implementing this operation in existing translators would be > a chore. Why? It would just be part of the migration framework... > Instead we can provide a translator that provides this reverse > authentication but otherwise proxies its underlying node, or perhaps > just gives out a unproxied port to it directly. This OTOH again sounds like a method for trusting code even if it's named by an untrusted sender... > This is has some other advantages. It would be possible to ``bless'' > code modules as appropriate for loading on a case-by-case basis. > Instead of loading any old file that happens to be owned by a trusted > user. I don't see how this would help in any way... Only the file owner can set a translator. And passive translators are started by the file system. All in all, exactly the same trust properties as with a "plain" file for all I can tell... > Another interesting possibility would be to let the code modules be > translators themselves. It would be kind of nice keeping it all the > needed functionality in a single file. Though I'm not sure how it > would be implemented. On the flip side it would mean that code would > be shared through a trivfs-like library, instead of in a separate > program which is usually prettier. No idea what you mean... > The only real problem with specifying the module by port is that the > receiver needs to load the exact same module and not a copy of it. I don't consider that a problem :-) -antrik-
