Share and learn in the Docker community.
I knew from my reading they say consider root in a a container to be root on the host. But I did not realize until now how easy it is for anyone on the system that was in the docker group to get a root shell if they so chose to do so.
http://reventlov.com/advisories/using-the-docker-command-to-root-the-host
The example says you can stop this with Selinux enabled but I have it enabled and it does not stop it.
So anyone have any idea how to mitigate this?
Make sure only people you trust with root on your host have permission to access the Docker socket. The default Ubuntu installation makes /var/run/docker.sock mode 0660 with a specific group owner docker for pretty much exactly this reason. (Making it group sudoers or wheel would make sense for the same reasons.)
Don’t enable the Docker remote network connection: anyone who can reach the TCP port has unauthenticated, unrestricted root access on your system. (Even if it’s bound to 127.0.0.1:2375, every local user now has root whether you wanted them to or not.) (I see frequent mentions of starting the Docker daemon with -H 0.0.0.0:2375 and it’s a really bad idea.)
Accept it as a risk if you’re doing something like using Docker in the context of a CI system where automated processes need to launch containers.
One solution is to think differently about the system that is running Docker Engine. In this context, Docker Engine is very much like a VMware ESXi hypervisor. You would never dream of giving anyone access to the system that runs the hypervisor except trusted admins, why would you give anyone access to the system that runs your Docker Engine except trusted admins? As David said, and the article proves, anyone in the docker group becomes a privileged user. Don’t assign it lightly.
We treat our Docker systems the same as any system that runs our cloud infrastructure. It’s hands off to only but a select few admins that maintain the system.
~jr
Thanks. So basically only mitigation is only make user id’s part of the docker group where you already give/expect that user to have root as their is nothing you can do to stop them to get root.
Docker >= 1.10 provides user namespaces, essentially mapping a container root user with uid 1 to a non-root user on the docker host. Check --userns-remap feature of dockerd. This might mitigate your problem.
However, know that the user namespace remapping is not turned on by default, and can break certain things like subuid/subgid in RHEL-style Linux installations.
I agree with the above consensus. Keep most people off the machine, and also be careful who who can launch containers. Just using the volume mounting functions, you can get in and get full read-write access (on by default!) to the host filesystem by mounting it inside a container, where you are root. Full write access means not only viewing the /etc/shadow file for passwords, but creating new users, overwriting active kernel memory (/dev/core or /proc/kcore), and a bevy of other mischief.
Has anyone compiled a list of what things user namespace remapping breaks? Kind of figured I would loose volumes.
Check section 2.8 of this for some links. The whole doc is full of useful stuff, but 2.8 speaks specifically to userns remapping.
https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.11.0_Benchmark_v1.0.0.pdf