GoKawiilThe other day a serious vulnerability was disclosed in one of the newer Linux distributions (the one led by the racist, so it isn't getting a mention here). The issue was interesting because it was caused by a non-standard Docker configuration that their installer applied by default, without alerting users that this configuration was creating a security risk. The end result was that any process running on these systems had the ability to elevate itself to root, without password, sudo or any prompts to the user.
While this incident did not affect me, it served as a reminder that it is difficult to set up Docker in a way that is secure. If you are interested in understanding what the issues with Docker are and what can be done to address them, then you are in the right place.
The problem with Docker
The security problems with Docker stem from the choice of using a client-server architecture that was made way back in the beginning. On a standard installation, the Docker daemon runs in the background under the root user, providing all the functionality through an API. Clients such as docker-cli send requests to this API through the Docker socket, which the server listens on.
Because the Docker daemon runs as the root user, an attacker that gains access to it can execute code with root permissions. You may think that this is just theoretical, or maybe an unlikely, highly complex and obscure vulnerability that only genius hackers can exploit. Well, think again.
Here is a simple example in which I show how I can obtain root access on my Ubuntu 26.04 system just using the docker command and without using a password:
# as a regular user, the following command fails $ ls /etc/sudoers.d/ ls: cannot open directory '/etc/sudoers.d/': Permission denied # but I can ask Docker to run this command and it works, no questions asked! $ docker run -v /:/host alpine:latest ls /host/etc/sudoers.d/ 90-cloud-init-users README
In case it isn't clear how this works, the docker run command above starts a standard Alpine Linux container, mounting the entire file system of the host under the /host path. Because the container is running under the root account through the Docker daemon, it has access to all files and thus can bypass any restrictions of the user that issued the docker run command. Note that there was no need to authenticate or enter any passwords, the command just worked. A slightly more elaborate malicious script could use the same technique to modify or exfiltrate system files, install cron jobs or other nasty things, all without the user noticing.
Now I don't want to lie to you. The above root escalation attack is not going to work on every Docker install out there. If you do a basic install of Docker, then "root escalation" does not really have much of a point, since under a default install the docker command is accessible only to the root user. If you wanted to use Docker from your regular user account you would be forced to run sudo docker and that requires authentication.
These types of attacks are possible because users often relax access permissions to the Docker socket in the name of convenience. A very common non-standard configuration change that people make is to add themselves to the docker group on their machines, which allows them to run the docker command without sudo . That is what I did for the demonstration I shared above, and also what the Linux distribution I referenced at the start did without notifying their users.
... continue reading