Solving the firmlink problem with io_restrict_auth (was Re: Adding entries to a directory)

[Carl Fredrik Hammar]

Hi,

On Tue, Nov 17, 2009 at 08:55:38PM +0100, olafBuddenhagen@gmx.net wrote:
> On Tue, Nov 17, 2009 at 01:15:59PM +0100, Carl Fredrik Hammar wrote:
> 
> > If run by any other user then it can only recreate the intersection of
> > credentials between unionfs and the client.  This isn't ideal, but it
> > does ensure that unionfs doesn't accidentally grant the client any new
> > permissions by mistake.
> 
> Actually I think this is just right... Whenever a client accesses a
> resource through a translator, it should be restricted not only by its
> own access, but also the translator's access.

Well, this naturally happens as the translator cannot possibly provide
more access then it already has.

> It is actually a problem that this policy is not followed whenever an
> intermediate translator hands out a "real" port to another translator,
> and the client reauthenticates it. (The so-called "firmlink problem".)

Having a ``proxy'' do an io_restrict_auth before passing on a port has
actually far reaching consequences.  Remember that firmlink is only an
odd use of the regular hand-off protocol when going from one translator
to another, so using this policy throughout the Hurd would mean we go
from a peer-to-peer authority scheme to a very hierachical one, where
each step from one translator to another can only mean less authority
for the client.

Note also that the fact that servers return an already authenticated
but restricted port that would solve the firmlink problem, rather the
client must refuse to reauthenticate ports on the server's request,
otherwise a malicious server could still trick the client.

Does this mean that the auth server isn't needed any more?  No, there is
still one case this doesn't cover: to extend the clients authority, with
setauth or the password server.  To do this the client must reauthenticate
all open ports in order for its new credentials to take effect.

Also to do this properly we need to improve io_restrict_auth so it
restricts the allowed operations to the intersection of the allowed
operations of two sets of credentials, and not just to the operations
allowed of the intersection of two sets of credentials.

I'm not sure if switching to such an authority scheme is a good idea
overall, but I do think it would indeed solve the firmlink problem.

Regards,
  Fredrik