23

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.

Improve this question

2 Answers 2

Reset to default
22

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.

Improve this answer
5
  • 4
    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
    Commented Nov 30, 2015 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
    Commented Nov 30, 2015 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
    Commented Nov 30, 2015 at 22:17
  • 3
    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
    Commented Feb 12, 2016 at 18:20
  • @RoryMcCune This facility is available but not enabled by default. See Docker security - Other kernel security features.
    – Ortomala Lokni
    Commented Jan 6, 2020 at 17:13
2

In 2023 we have a kernel feature called "User Namespaces" which is used for "Unprivileged Containers" (this has existed for some years, not sure how many).

root UID 0 in the container will be UID 100000 on the host system, so unless you have user numbers on the host system in the 100000+ range (they typically start at 1000), then there is not a security risk outside of kernel-level security risks.

Since Docker is merely a collection of tools interacting with LXC (or at least for the Linux guests on the Linux Host or Linux VM within Windows / Mac), it would be very bizarre to me if Docker is intentionally not using the best security features available.

However, from this documentation it's not clear to me what the default behavior is:

It sounds as though the remapping must be turned on by setting the config value for remapping to default.

However, I'm not clear if default is the default value... or not.

Improve this answer
1
  • It's worth noting that whilst user namespaces, as designed, should improve security, there have been some Linux kernel vulnerabilities which were more easily exploited when it was enabled. e.g. willsroot.io/2022/01/cve-2022-0185.html which needed CAP_SYS_ADMIN at host level or in a user namespace.
    – Rory McCune
    Commented Apr 5, 2023 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .