Re: Solving the firmlink problem with io_restrict_auth

[Carl Fredrik Hammar]

Hi,

On Sun, Nov 22, 2009 at 08:19:01PM +0100, olafBuddenhagen@gmx.net wrote:
> On Thu, Nov 19, 2009 at 02:58:07PM +0100, Carl Fredrik Hammar wrote:
> > On Tue, Nov 17, 2009 at 08:55:38PM +0100, olafBuddenhagen@gmx.net
> > wrote:
> 
> > > 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.
> 
> Yeah, so the question is: is this a bad thing? With the current scheme,
> the only way to make translators safe is to never follow translators set
> up by untrusted users. (Which BTW is also the policy used by FUSE by
> default.) Would changing the authentication scheme preclude any
> desirable (safe) use cases that are possible presently?

I can't think of any use cases.  But I do wonder if the problem is inherit
it to all links.  OK, so you can detect and avoid symlinks if you want
to be safe, but how often is this actually done?  And while hard links
only allows linking to non-directories, it still has the same problems,
e.g. ``ln /etc/shadow /var/mail/cfhammar'' could make an MRA clobber
the systems passwords.  It seems that the firmlink problem is really
just a generalization of the ``link problem''.

Is it really worth the effort to limit the problem or should we perhaps
just stipulate that a users files and directories should not be trusted?
I'm not convinced either way...

> > 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.
> 
> Yes, that was exactly my point. IMHO this should be changed -- though
> I'm not sure how exactly...

I have been thinking about how this, and it seems that *any*
reauthentication -- not just server requested -- can be used to trick
the client.  When a client reauthenticates a port, the server can simply
forward the request to a server precious to the client, and thus trick it.

It is clear that restrictions must be remembered across
reauthentictations.  However, a client's own credentials cannot be
treated as a restriction by a server, otherwise clients cannot increase
their access by reauthentication, and so a malicious server still has
an opening to trick the client.

It does work if the client remembers the restrictions, which makes
sense since it is the one being tricked.  In this case, it can simply
re-restrict ports after reauthentication.  Of course, this means the
client must be aware of the server's credentials, so it can later
re-restrict any ports returned by it.

The changes required for this is that authentication also returns the
server's credentials to the client, which could possibly be done through
reverse authentication, but should probably be added directly to the
normal authentication protocol.  It also requires that client keeps a
``paper-trail'' for each port, so that it knows the credentials of the
server that returned the port, and the credentials of the server that
returned *that* port, and so on...

> > 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 yet convinced that this is really much of a problem in practice
> :-)

If we indeed want to do restrictions on every translator transition,
I think it will become a problem in practice.

Regards,
  Fredrik