My question is probably more about the LXC than about Docker, but I wonder what are the security mechanisms to prevent a root user inside a Docker image to access the whole host.

More precisely, I wonder what are the limit of the capacities of such root user before you reach a point where you can do dangerous things.

Typically, for educational purpose, I need students to load a kernel module from inside a Docker image. Would this kernel module be accessible from the whole system? And, if not, what are the limits and how are the LXC dealing with memory separation inside kernel-space?

For short, I would like to know how far we can go with LXC without making it harmful for the system.


Short answer: Root on the docker container can break out of jail and compromise system.

Docker is meant to simplify the life of developers and sysadmins, not about containing programs isolated from each other. There's some safety features backed in, but they are not the main intention. The idea is to ship a container with the application and every pre-requisite packed together and let the user start it without hassle, not to keep misbehaved users or applications in check.

There are some exploits that make possible to a user running root applications inside a container to break free from the container and compromise the host. Docker took some measures to fix those loopholes, but they are cumbersome to employ.

This Docker security article tells you to not let users load modules. To allow module loading you allow the user to easily break free of the jail. If you want security AND let people load modules, use a VM.

You can create light virtual machines using Xen, VirtualBox or Kvm, and they will be isolated from each other. You can give all your users root on the image, and they will not be able to mess with each other nor with the host system.

  • 3
    I am a bit surprised because people from Docker say that a root user can break out only under certain circumstances. For example, this page states that you should "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". I don't know who to believe, now... But, I guess that if you map the root user to a non-root user, you won't be able to mount a kernel module. Is that what you mean ? – perror Nov 30 '15 at 18:04
  • 1
    Just a side note about my comment... The page I cited was just planning to map the root user inside the Docker image to a non-root user, but it was in 2013, I don't know what is their current status about it... – perror Nov 30 '15 at 18:18
  • 2
    After reading a bit more about the topic, I finally got convinced that you were absolutely right. The maximum rights that you can give to the root user is to allow anything but NOT to manipulate the kernel (loading a module is to be avoided). And, even, allowing a user to get root inside the Docker seems to be living dangerously. – perror Nov 30 '15 at 22:17
  • 2
    Worth noting that with Docker 1.10+ and User namespacing, the root user inside a container is no longer the root user outside of the container. whilst that reduces the risk of breakout, it also prevents this scenario of loading a kernel module as the root user inside the container wouldn't have the appropriate rights outside the container. – Rory McCune Feb 12 '16 at 18:20
  • @RoryMcCune This facility is available but not enabled by default. See Docker security - Other kernel security features. – Ortomala Lokni Jan 6 '20 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.