Illusion of isolation in Docker

In my company, I was recently given access to the docker group to run containers. This sounded standard, but it led me to discover how I could gain functional root privileges on the host machine just by being a member of this group.

To understand how, let’s agree on a common Docker principle: The Docker Daemon runs as a root process.

The Docker CLI interacts with the daemon through a Unix socket (/var/run/docker.sock). If you have access to the CLI (which the docker group gives you), you have read and write access to this socket.

The Exploit: Breaking the Isolation

In general, Docker images run as isolated processes. But something "magical" happens when we run a container by mounting the host’s root file system.

Consider this command:

docker run -v /:/host_root -it centos bash

Here, the container now has read/write access to the host system's root directory (/). By mounting it as a volume, we bypass the container's Union Filesystem (and lose the Copy-On-Write isolation) for that specific path.

The chroot trick

At this stage, we have just mounted the file system. If I try to install a service (e.g., yum install tree) inside the container normally, it installs in the container's /usr/bin, not the host's.

But, suppose I run this command inside the container:

chroot /host_root

The chroot (Change Root) command changes the apparent root directory for the current running process.

1. I am telling my process: "Treat the mounted /host_root as your actual / directory."


2. The root user in a container usually has a UID of 0.


3. The Linux Kernel allows UID 0 to do whatever it wants.

At this point, even though I’m still inside a container, I’m operating directly on the host’s filesystem with root-level permissions — which is just as dangerous in practice.

If I install a package now, it installs on the host. If I delete a file, it is deleted from the host.

How to manage this?

Since granting docker group access is essentially granting root access, here is how we can secure it:

1. 
   Rootless Docker: Run the Docker daemon as a non-root service. However, rootless Docker comes with trade-offs: reduced performance and limitations around direct access to storage and the networking stack. So it has to add some wayaround, that incurs additional overhead.


2. 
   Read-Only Mounts: If you must mount the host filesystem, enforce read-only access: docker run -v /:/host_root:ro ...


3. 
   Principle of Least Privilege: Try adding minimal users to the docker user.


4. 
   Secure Dockerfiles: When creating images, explicitly create a non-root user.
   Example of a secure user setup:
   

RUN groupadd -r container_user && useradd -r -g container_user container_user

RUN chown -R container_user:container_user /host_root

USER container_user