Re: -mm -> 2.6.13 merge status (fuse)

[Miklos Szeredi <miklos@szeredi.hu>]

> > It's related to the problem of a suid program accessing synthetic
> > filesystem, and filesystem doing something bad to suid program (make
> > it hang, supply bogus data ...).  This can be solved by "squashing"
> > suid for the whole namespace (basically the Plan 9 solution).
> > Unfortunately this is not really practical in Linux/Unix.
> > 
> 
> Just to make sure I understand you - if I don't squash suid for the
> entire name space, a user could mount a malicious synthetic (even with
> NOSUID) and then launch an SUID app from an inherited mount which
> would then traverse to the malicious synthetic.

Yes. 

> That's a nasty case I hadn't considered before -- however, what's the
> potential damage there?  The user could hold up progress of the SUID
> app that they launched, but that wouldn't necessarily impede system
> progress since system-critical suid apps wouldn't be typically
> launched by a user.  I suppose there is the possibility that if
> multiple instances of such an SUID app share a global lock you could
> get into trouble -- do we have any concrete example apps that would
> exhibit this kind of behavior?

I don't know any.  But with 'sudo' the potential set of SUID apps is
basically infinite, so you'd have a hard time proving that this sort
of situation won't arise.

> Are there other vunerabilities that I'm missing?

Another theoretical possibility is that you make the SUID app consume
some resource by feeding it a large-file/deep-directory/etc that quota
would otherwise prevent (you can't do quota on a synthetic filesystem,
without the filesystem's cooperation).

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/