Are there known security risks in running docker with user namespace disabled?

Question

I've been playing with Docker in Ubuntu using DigitalOcean's Dokku image. Everything seems to work fine. Just checking how the installation of docker is done I found that lxc-checkconfig reports User namespace: Disabled.

This tutorial explain that is because the kernel wasn't compiled with CONFIG_USER_NS=y so it can be achieved by recompiling.

Since everything works fine I'm wondering if there's something I missing about this user namespace thing, for instance, a security benefit.

So, why is the functionality added by enabling User Namespace? What risks or known issues are there if I keep it disabled?

Answer 1

As of 0.7.3, Docker doesn't use the user namespace (yet). Therefore, enabling it doesn't change anything from a security point of view.

Once the user namespace code (and the relevant user-space tools) are stable, Docker will use it to provide additional security.

As indicated by the doc that you quoted, the user namespace will allow "containment of the container root user". This means that the root user inside a container will not necessarily be mapped to the root user outside the container (i.e. on the host). That way, a process can run as root in the container, but actually be mapped to a normal (non-privileged) user outside.

In the future, user namespaces might also allow to start containers without requiring root privileges on the host; but it will take a while since many steps in the container setup require those privileges (e.g. setting up the network).

Answer 2

As detailed in "User namespaces have arrived in Docker!" (Phil Estes, ESTESP), this will be available in the experimental branch of docker 1.9 (Nov. 2014). PR 12648.

One of the most important features of user namespaces is that it allows containers to have a different view of the uid and gid ranges than the host system.
Specifically, a process (and in our case, the process(es) inside our container) can be provided a set of mappings from the host uid and gid space, such that when the process thinks it is running as uid 0 (commonly known as “root”), it may actually be running as uid 1000, or 10000, or even 34934322. It all depends on the mappings we provide when we create the process inside a user namespace.

Of course, it should be clear that from a security perspective this is a great feature as it allows our containers to continue running with root privileges, but without actually having any root privilege on the host.

See more at the "Experimental: User namespace support" documentation page (for an experimental docker build, from experimental.docker.com) .

docker daemon --userns-remap=default

Note that some of standard Docker features are currently incompatible when running a Docker daemon with experimental user namespaces enabled, like sharing namespaces with the host (--pid=host, --net=host, etc.) or with other containers.

That user mapping ability is for now per-daemon, not yet per container (that would require a Linux kernel evolution which be in the work, but not). sharing namespaces with the host (--pid=host, --net=host, etc.)

Finally:

Due to the need to segregate content in the Docker daemon’s local cache of layer data by the mappings provided, once you use an experimental build with user namespaces, the root of your graph directory (/var/lib/docker by default) will have one additional level of indirection which correlates to the remapped root uid and gid.

For example, if the remapping user I provide to the --userns-remap flag has subordinate user and group ranges that begin with ID 10000, then the root of the graph directory for all images and containers running with that remap setting will reside in /var/lib/docker/10000.10000.
If you use the experimental build but don’t provide user namespace remapping, your current content will be migrated to /var/lib/docker/0.0 to differentiate it from remapped layer content.

Answer 3

The answer is: there's potential risk in not having user namspace. I inferr this from this article on LXC on Ubuntu:

Privilege

The container administration tools must be run with root user privilege. A utility called lxc-setup was written with the intention of providing the tools with the needed file capabilities to allow non-root users to run the tools with sufficient privilege. However, as root in a container cannot yet be reliably contained, this is not worthwhile. It is therefore recommended to not use lxc-setup, and to provide the LXC administrators the needed sudo privilege.

> The user namespace, which is expected to be available in the next Long Term Support (LTS) release, will allow containment of the container root user, as well as reduce the amount of privilege required for creating and administering containers.

The answer to the exact risks are not fully clear to me, but now you know there will be benefits of having the user namespace in ubuntu's next LTS, which I think is 14.04 coming in April 2014.

Any extra information to improve the answer is heavily appreciated.