One reason why user namespaces keep enabling Linux kernel security issues

December 7, 2016

If you've been following Linux kernel security issues over the past few years, you've probably noticed that one common element that keeps reappearing over and over is 'user namespaces' (most recently in CVE-2016-8655). At this point you may reasonably wonder not just what user namespaces are but why they keep being involved in so many security problems.

The general idea of kernel namespaces is covered in the namespaces(7) manpage and user namespaces have their own specific manpage, user_namespaces(7) . From our perspective, the simple version of what user namespaces do is that they give a process or a group of them an isolated world in which they can effectively be root.

(The manpage has more details and a better explanation.)

By itself this is not a security problem, at least in theory. While you may have elevated capabilities in your user namespace, you're only supposed to be able to use them on things in the kernel that are safe for regular users to manipulate in an isolated environment. For example, you can't use your nominal root permissions to mount any old filesystem with any old mount options; only a very few filesystems will let themselves be mounted this way.

(Sometimes this isn't quite what happens in practice.)

The problem is that even when everything works the way the theory has it, user namespaces still expose a lot of code in the kernel to normal users that was previously only really accessible to root. That code has not necessarily been thoroughly hardened against various sorts of nasty things, so if you can find some issue with some part of it you can then leverage access to it from a user namespace to turn what was a 'root can damage the system, big deal' issue into an 'anyone can do nasty stuff to the system' big deal issue. The actual bugs are not in user namespaces, but user namespaces enable access to them by making a lot more code in the kernel reachable by ordinary users.

(It's my view that these bugs are going to keep surfacing for years to come. User namespaces expose a lot more kernel code to users, that code's not going to be thoroughly audited any time soon, and the user namespace people seem to like adding more and more things that are nominally safe for them to affect.)

Another sort of kernel security issue created by the existence of user namespaces is interactions between operations that are now allowed in user namespaces and other things in the system. CVE-2015-8709 is an example of this; the root cause was an assumption about what a particular security check covered (see the discussion in the kernel fix). Security checks in general are a complex system, with all that that implies.

(See also Anatomy of a user namespaces vulnerability and this lwn.net overview of user namespaces and namespaces in general.)


Comments on this page:

By Ben Hutchings at 2016-12-08 01:30:36:

This is why Debian's kernel is patched to not allow unprivileged users to create namespaces. (There is a sysctl to override that. Ubuntu has the same sysctl but the opposite default.)

Written on 07 December 2016.
« My RPM build setup no longer works on Fedora for some packages
Trailing text, a subtle gotcha with Go's fmt.Sscanf »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 7 02:18:05 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.