On Tue, Nov 11, 2014 at 09:37:10AM -0600, Eric W. Biederman wrote: > > Maybe I'm being dense, but can someone give a concrete example of such an > > attack? > > There are two variants of things at play here. > > There is the classic if you don't freeze your context at open time when > you pass that file descriptor to another process unexpected things can > happen. > > An essentially harmless but extremely confusing example is what happens > to a partial read when it stops halfway through a uid value and the next > read on the same file descriptor is from a process in a different user > namespace. Which uid value should be returned to userspace. Fuse device doesn't currently do partial reads, so that's a non-issue. > Now if I am in a nefarious mood I can create a unprivileged user > namespace, open /dev/fuse and mount a fuse filesystem. Pass the file > descriptor to /dev/fuse to a processes that is in the default user > namespace (and thus can use any uid/gid). With that file desctipor > report that there is a setuid 0 exectuable on that file system. Yes, and this would also be prevented by MNT_NOSUID, which would be a good idea anyway. I just don't see the reason we'd want to allow clearing MNT_NOSUID in a private namespace. So we don't currently see a use case for relaxing either the MNT_NOSUID restriction or for relaxing the requirement on the user namespace the fuse server is in. Is that correct? If so, we should leave both restrictions in place since that allows the greatest flexibility in the future, is either of those needs to be relaxed. > > That might also help me understand how exactly user/pid namespaces work... > > The idea of user/pid namespaces is to translate uid, gids and pids at > the edge of userspace into a kernel internal form that can be use > everywhere. In this case we get into the subtlties of which > translations make sense. I mean, what's the point of translating uid, gids and pids? What are the use cases? What are the rules on the translations between parent and child namespaces? Is all this documented anywhere? Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
