Messages in this thread | | | Date | Wed, 22 Jun 2005 11:48:00 -0500 | From | Eric Van Hensbergen <> | Subject | Re: -mm -> 2.6.13 merge status (fuse) |
| |
On 6/22/05, Miklos Szeredi <miklos@szeredi.hu> wrote: > > > > I'm confused why everything has to be remounted nosuid. I understand > > enforcing synthetics to be mounted nosuid, but not the rest of the > > file systems. > > 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.
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?
Are there other vunerabilities that I'm missing?
-eric - 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/
| |