Hi Chris, I believe what you refer to is a well-known issue with docker. I have this reference from Apr. 2015: https://fosterelli.co/privilege-escalation-via-docker.html
This is how docker works. The most easy mitigation is NOT to add a user to the docker group. This way, you will always invoke docker with 'sudo docker', and then it's explicit that you're running something as root. Explicit better than implicit maybe, at least no more "accidental". Second thing, as you noted, docker can access a directory on the host only if you share it with '--volume' or '--mount' or something. So it's not really accidental if then the process in the container writes to the host directory. It's something that you authorized explicitly. And the fact that it's a root access is due to the fact that the container is run as root, as you correctly noted. If you download and run a containerized app as root, and share your /home with the container, then you'd better trust this app 100%. > a search for "docker" on backports.debian.org returned no results Indeed, docker sits on top of 100+ dependencies, backporting would mean backporting all those dependencies. Plus maybe the go compiler and the go library. It would be such a huge work that it's not realistic. Since Go is a statically compiled language, there's little value in backporting anyway. You can just try your luck and install the docker from Debian unstable into your Debian stable. It might work. Maybe some bugs would be lurking here and there in the dark, maybe not, I just don't know. As for rootless mode, it should be indeed supported in the 20.10 version. I myself never tested it. If I'm not mistaken, everything is present in the 20.10 package provided in Debian unstable to run the rootless mode. You can give it a try :) All the best, Arnaud On Fri, Jan 8, 2021 at 10:48 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. > > Cheers! > -Chris > > > -- System Information: > Debian Release: 10.7 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.19.0-13-amd64 (SMP w/2 CPU cores) > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), > LANGUAGE=en_CA:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages docker.io depends on: > ii adduser 3.118 > ii iptables 1.8.2-4 > ii libc6 2.28-10 > ii libdevmapper1.02.1 2:1.02.155-3 > ii libltdl7 2.4.6-9 > ii libnspr4 2:4.20-1 > ii libnss3 2:3.42.1-1+deb10u3 > ii libseccomp2 2.3.3-4 > ii libsystemd0 241-7~deb10u5 > ii lsb-base 10.2019051400 > ii runc 1.0.0~rc6+dfsg1-3 > ii tini 0.18.0-1 > > Versions of packages docker.io recommends: > ii ca-certificates 20200601~deb10u1 > ii cgroupfs-mount 1.4 > ii git 1:2.20.1-2+deb10u3 > ii needrestart 3.4-5 > ii xz-utils 5.2.4-1 > > Versions of packages docker.io suggests: > pn aufs-tools <none> > pn btrfs-progs <none> > pn debootstrap <none> > pn docker-doc <none> > ii e2fsprogs 1.44.5-1+deb10u3 > pn rinse <none> > pn xfsprogs <none> > pn zfs-fuse | zfsutils <none> > > -- no debconf information >
