How to mitigate privilege escalation in Docker Containers to secure the host FS

Question

A question on secuity. I want to allow non-root users to deploy containers on say a cluster, I'd be concerned if they could mount host directories and then escalate to root privileges inside the container. I gather from the articles below that the feature for mapping a container-root-user to a host-non-root-user is still in the ether? The article itself seems to be relatively old, I'm curious to know how developed these features are.

"Recent improvements in Linux namespaces will soon allow to run full-featured containers without root privileges, thanks to the new user namespace. This is covered in detail here. Moreover, this will solve the problem caused by sharing filesystems between host and guest, since the user namespace allows users within containers (including the root user) to be mapped to other users in the host system.

The end goal for Docker is therefore to implement two additional security improvements:

1) map the root user of a container to a non-root user of the Docker host, to mitigate the effects of a container-to-host privilege escalation;

2) allow the Docker daemon to run without root privileges, and delegate operations requiring those privileges to well-audited sub-processes, each with its own (very limited) scope: virtual network setup, filesystem management, etc.

https://docs.docker.com/articles/security/ http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/

Answer 1

I gather from the articles below that the feature for mapping a container-root-user to a host-non-root-user is still in the ether?

The article "User namespaces have arrived in Docker!" (Phil Estes, ESTESP), illustrates it is not in the ehter anymore!
It will be available in the experimental branch of docker 1.9 (Nov. 2014). PR 12648.

The user mapping is confirmed:

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.

Update February 2016:

As noted in the comments by Phil E

As of this past week, Docker 1.10 was released, and user namespaces was included as a feature.
A quick note that because of the graduation from experimental to master, the documentation now resides in the daemon command-line reference page.

Answer 2

Not so much:

• Allow the docker daemon to run as non-root on the host system
• Having non-root privileges on the host and root inside the container