Re: Solving the firmlink problem with io_restrict_auth

[olafBuddenhagen]

Hi,

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?

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

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

-antrik-