Control: retitle -1 docker.io: version in Buster does not support "rootless mode" Control: fixed -1 20.10.0~rc1+dfsg2-1 Control: severity -1 wishlist
On Fri, Jan 8, 2021 at 11:55 AM Chris <debb...@chris.oldnest.ca> wrote: > > Package: docker.io > Version: 18.09.1+dfsg1-7.1+deb10u2 > Severity: critical > Tags: security > Justification: root security hole > > Dear Maintainer, > > Unless I'm missing something, any program running in a Docker container > using the Docker version currently available in Debian stable has a > trivial-to-exploit path to full, persistent, root privilege escalation. > > Docker v18 only works when it's SUID root. Processes running as root > *inside* the container accessing the *host* filesystem do so as root *on > the host system* unless they are internally configured to map to a > regular user on the host system. (According to my rough and inexpert > understanding of the situation.) > > I installed docker.io from the official Debian stable repos, added a > user to group "docker" in order to be able to use it, downloaded and > ran a containerized program, and noticed that the program in the > container was creating files and directories with root ownership in my > home directory on the host system. > > A quick search of the web turned up a tutorial showing how easy it is > to exploit this situation: > https://medium.com/@Affix/privilege-escallation-with-docker-56dc682a6e17 > ...as well as tutorials on how not to *accidentally* create root-owned > files on the host system when setting up Docker containers, eg: > https://vsupalov.com/docker-shared-permissions/ > > I discovered that newer versions of Docker have a "rootless mode" that > doesn't require the main Docker executable to run SUID root (though it > does rely on a couple of narrow-scope SUID helper utilities), which > should hopefully mitigate this situation to a considerable extent: > https://docs.docker.com/engine/security/rootless > This capability was introduced as experimental in v19.03 and "graduated > from experimental" in v20.10. Unsurprisingly, it requires that > unprivileged_userns_clone be enabled. > > The version of docker.io in the Buster repos is 18.09 at the time of > this writing, and a search for "docker" on backports.debian.org returned > no results. While I am aware of the controversy around > unprivileged_userns_clone, I gather that it will be enabled by default > in Bullseye (starting with kernel 5.10, I believe) because at this point > it presents the lesser evil. > > Unless I'm gravely mistaken about the situation, I'd much rather enable > that potentially-exploitable kernel feature and run Docker in "rootless > mode" than continue running Docker in a configuration that's so easily > exploitable there are tutorials on how to prevent accidentally creating > files as root when using Docker containers as a regular user. > > Accidental. Root. Filesystem access. As a regular user. > > I propose that — as a minimum — backporting the version of Docker in > Bullseye (currently v20.10) to Buster be treated as an urgent security > priority, so that users at least have the option to install Docker from > an official Debian source and use it in the less-dangerous "rootless > mode". > > Further, Docker is widespread and gaining popularity fast, it's already > in the Debian stable repositories, and the only way the version > currently in stable can be used is *shockingly* dangerous. Given all > that, I'm inclined to suggest that pushing Docker v20.10 to > buster-security along with configuration that enables > unpriv_userns_clone and sets Docker up to run in "rootless mode" should > be seriously considered. > > Or my understanding of the situation could be profoundly wrong. I'm > pushing the edge of my technical understanding here, and I would be > thoroughly pleased to be wrong about this whole thing. > This is how docker designed. If you give someone the permission to use docker daemon, then it means you give out the root permission. Rootless is a new feature, so this bug is a feature request, not a security bug. docker is written in Go, you can install the 20.10 version from unstable even if you are on buster. But it's not recommended anyway. -- Shengjing Zhu
