Re: Code trust by reverse authentication

[Carl Fredrik Hammar]

Hi,

On Mon, Jun 29, 2009 at 12:05:26AM +0200, olafBuddenhagen@gmx.net wrote:
> 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...

Yes, but there's nothing stopping the sender from using a filesystem
that doesn't implement it properly.  It can even implement it itself.

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

Precisely.

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

Whoops, I meant letting the filesystem authenticate against the receiver.

> > Of course implementing this operation in existing translators would be
> > a chore.
> 
> Why? It would just be part of the migration framework...

Not if the functionality needs to be in the filesystem.  :-)

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

Yes, this is what I meant.

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

Well, it's more specific trust.  We can now explicitly determine that
the owner meant that the file can be trusted to load code from it.
Rather then say a file in `/tmp' that was accidentally made writable for
the sender, which would allow it to inject arbitrary code.  (I assume
the receiver is more careful with permissions on code modules.)

Not something I require of the mechanism, rather it's a nice side-effect.

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

Instead of proxying a normal .so file, the translator would allow
the client to load parts of the translator's own binary, which would
implement a mobile object.

As I said, this would be cool in some ways, but also weird.  :-)

> > 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 :-)

Consider Alice who wishes to use ioctls provided by Bob.  Now, Alice
trusts Bob enough to use his servers, but not enough to load code provided
by him.

After inspecting the source code of the ioctl handler, she trusts this
particular code provided by Bob.  So she copies the source code and
compiles it to an identical copy of the module used by Bob's server.
However, she still can't use the server since it provides a reference
to Bob's copy, which he can modify at any time.

Now I know you think that using other user's servers is a dubious
use-case.  But code is just plain data, it should be enough to trust
a copy.

I can't think of a way to support this use case if the module is specified
by port.  It can only be done when specified by symbolic name, I think.
If we want to make sure the code is identical, the sender could provide
a SHA1 hash of the code it's using, or something.  Such a check would
make it impossible to use a module compiled with different flags though...

Anyway, I keep going back and forth between symbolic names and port
references.  I'm not really convinced either way yet.

Regards,
  Fredrik