Code trust by reverse authentication

[Carl Fredrik Hammar]

Hi,

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.  And there doesn't seem to be anyway
to check who controls the actual translator either.

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.

Of course implementing this operation in existing translators would be
a chore.  And I don't know if it will ever be useful for anything else,
though the concept is generic enough.

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 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.  For a
normal user to provide its own module, it would now be a simply a matter
of blessing the module and then pointing the mobile object provider at it.
For instance, settrans libfoo.so /hurd/bless-code.

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.

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.
This is a reasonable requirement for optimization, for which the extra
assurance that the code is exactly the same increases reliability.
But I'm not so sure about ioctls...

Regards,
  Fredrik