Anatomy of a user namespaces vulnerability [LWN.net]

Anatomy of a user namespaces vulnerability

Posted Mar 21, 2013 0:13 UTC (Thu) by butlerm (subscriber, #13312)
Parent article: Anatomy of a user namespaces vulnerability

Wouldn't the combination of CLONE_NEWUSER and about half of the other CLONE_xxx options lead to potential security risks as well? After all one may request that processes in two completely different security contexts should share things they probably shouldn't - signal handlers, thread groups, memory spaces, SYS V semaphores, and so on.

It is hard to see how most of that could possibly be useful in such a combination, and some of it looks positively dangerous. And if that is the case, wouldn't the conservative option be to disable the combination of CLONE_NEWUSER with everything that isn't recognized as necessary and/or useful?

Perhaps it might also be worthwhile to consider renaming the CLONE_xxx options to clearly indicate which options actually clone things, which ones share things, and which ones create new things. With aliases for backward compatibility of course.

(Log in to post comments)

Anatomy of a user namespaces vulnerability

Posted Mar 21, 2013 0:57 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

I also wonder about these 'odd' combinations.

One thing I've found is that any time I tend to think "there's no reason for anyone to use _that_ combination", someone ends up running into a case where it's exactly the right thing to use.

You almost need these things to be configurable. The problem is in figuring out how to do that without imposing unacceptable overhead in every fork() call.

I wonder if the 'traditional' flags and combinations could be whitelisted into a very fast special case, and combinations that use the new flags/features branch off to a more flexible/detailed set of checks that may be a bit slower.