[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code trust by reverse authentication
From: |
olafBuddenhagen |
Subject: |
Re: Code trust by reverse authentication |
Date: |
Mon, 29 Jun 2009 00:05:26 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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-