bug-hurd
[Top][All Lists]
Advanced

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




reply via email to

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