The docker daemon runs as root. And as such, it can access anything initially. If your container doesn’t explicitly (or implicitly) change the uid or drops capabilities, the container also runs as root (ok, IIRC some capabilities are always dropped, but the container stays almost root). It’s still locked in its own little sandbox, but the mounting of those paths etc. happens with root.
If you enter a docker command (docker run ..., docker build ..., …) this command will not run the containers by themselves, but instead call said docker daemon (that is running as root) by using a socket (/var/run/docker.sock).
To only allow trusted users to interact with the docker daemon, this socket can only be accessed by root or by users in the docker group. That’s why you usually need to type sudo docker run.... Sadly many tutorials tell you to just blindly add your user to the docker group so that you do not need to use sudo to interact with docker. BUT that now means that you gave you or those users basically full access to your whole filesystem (and thus system configuration) without sudo. Any programs (or viruses or AI Agents or…) running with these user accounts also get this group and thus docker’s capabilities.
That’s why you should NEVER add your user to the docker group or enable passwordless sudo, as you’re just one simple command/tool/script/prompt/… away from a privilege escalation.
You can configure docker to run rootless with only your user’s capabilities and rights, but at that point… Why configure docker to do something that other docker compatible projects like Podman offer out of the box?
Yeah, I’m more familiar with Podman, which I always use in rootless mode. Definitely seems like a mistake to give an LLM shell access with a user account in the docker group…
The docker daemon runs as root. And as such, it can access anything initially. If your container doesn’t explicitly (or implicitly) change the uid or drops capabilities, the container also runs as root (ok, IIRC some capabilities are always dropped, but the container stays almost root). It’s still locked in its own little sandbox, but the mounting of those paths etc. happens with root.
If you enter a docker command (
docker run ...,docker build ..., …) this command will not run the containers by themselves, but instead call said docker daemon (that is running as root) by using a socket (/var/run/docker.sock).To only allow trusted users to interact with the docker daemon, this socket can only be accessed by root or by users in the docker group. That’s why you usually need to type
sudo docker run.... Sadly many tutorials tell you to just blindly add your user to the docker group so that you do not need to use sudo to interact with docker. BUT that now means that you gave you or those users basically full access to your whole filesystem (and thus system configuration) without sudo. Any programs (or viruses or AI Agents or…) running with these user accounts also get this group and thus docker’s capabilities.That’s why you should NEVER add your user to the docker group or enable passwordless sudo, as you’re just one simple command/tool/script/prompt/… away from a privilege escalation.
You can configure docker to run rootless with only your user’s capabilities and rights, but at that point… Why configure docker to do something that other docker compatible projects like Podman offer out of the box?
Yeah, I’m more familiar with Podman, which I always use in rootless mode. Definitely seems like a mistake to give an LLM shell access with a user account in the
dockergroup…Assuming you get to check every (docker) command and then potentially deny it, it might work. But that’s annoying AF depending on what you use it for.