Re: Solving the firmlink problem with io_restrict_auth

[olafBuddenhagen]

Hi,

On Sun, Nov 29, 2009 at 08:12:38PM +0100, Carl Fredrik Hammar wrote:
> 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:

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

Great, that makes two of us! ;-)

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

Well, while I didn't actually realize that hardlinks are affected too, I
did point out in some other discussion before that many translator
problems actually apply to symlinks as well. The problems with symlinks
are generally worked around by special handling in applications. For
translators, we need to find a more generic solution, which doesn't
require each application to be aware of all possible translator
variations... (Or in fact of the existence of translators at all.)

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

Well, "normal" files (with the well-known semantics all programs should
be able to cope with) are a subset of tranlator functionality, not the
other way round... We are really looking at the generic case here.

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

I don't think this actually works... But I have no time presently to
think it through properly :-(

The "tricking" part in the firmlink problem is not that the client
reauthenticates against the "wrong" server, but rather that it is made
to perform some action with its own authority by the malicious
translator's request...

> It is clear that restrictions must be remembered across
> reauthentictations.

I was thinking more along the lines of abandonning reauthentication on
lookups alltogether...

The problem is that while a translator can only hand out a port to
another translator that conveys a subset of its own authority, the
client exchanges it for a port with the client's authority upon
reauthentication. So in the end it's as if the translator has provided a
port with more authority than it itself posseses -- which, as I observed
a while back in another discussion, breaks the capability concept. This
is really the root problem IMHO.

As you pointed out yourself, without reauthentification, the authority
can always be only decreased on lookups, never increased. You can't
access a server with more privileges under a less privileged filesystem.
While abandoning this possibility would change a very fundamental part
of the Hurd design, I'm not sure that this would be a bad thing -- it is
a very dangerous feature; and as I said above, I don't see any actually
desirable use cases for it...

It would in fact still be possible to do reauthentication where really
desired -- only never do it automatically in unsuspecting clients not
aware of the implications...

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

Perhaps I am missing something -- but what's the point in
reauthenicating at all, if we just apply the same restrictions anyways?
:-)

-antrik-