At $WORK, we have discussed at length security issues as they relate to Docker and the Linux lxc technologies. Our general takeaway is that you cannot ever really trust an image that you didn’t build yourself. As Daniel Walsh of Red Hat explains in his article Docker Security with SELinux, it appears that those concerns are valid.
The problem here revolves around namespaces, and the fact that not everything in Linux is namespaced. Consider /sys, /proc, /dev/sd*, /dev/mem, etc. So what we have here is that root inside the containers effectively has root access to any of these file systems or devices. If you can somehow communicate with them, then consequently, you can own the host with little effort.
Then, What Do?
You should only run Docker images that fit one of the following criteria:
- You have built the image yourself, from scratch
- You have received the image from a trusted source
- You have built the image from a third-party’s Dockerfile, which you have fully read, and understood
Also be careful with your “trusted” source. The base images are probably OK. Images released by, say, Red Hat or Canonical are probably OK. Images in Docker Hub, Docker’s official image registry, might not be. That’s not a hit on the Docker guys – it’s because there are over 15,000 images they’d have to have verified manually to be sure.
Don’t Forget Traditional Security Practices
Finally, you need to be concerned with the security of your Docker containers as well – just as concerned as if the stuff in the container were running on a regular server. For example, if someone were to compromise the webserver you have running in a container, and get escalated root privileges, then you effectively have a compromised host.
Be careful out there. Maintain the security of your containers, and only run images you can fully trust.