On Sat, Jan 9, 2021 at 2:00 AM Chris Mitchell <ch...@oldnest.ca> wrote:
> On Fri, 8 Jan 2021 11:38:59 +0700 > El boulangero <elboulang...@gmail.com> wrote: > > > 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". > > This makes some sense. Given that it's apparently well-known that > allowing a user to run Docker essentially gives them unrestricted root > access, I'm rather surprised that no warning was presented at any point > in this process. > > > 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. > > Ah, okay. This, I think, is where I fundamentally misunderstood the > situation. I was picturing the "containerized app" as a single entity, > presenting an all-or-nothing choice between "accept that anything you > run in a Docker container has root access to your whole filesystem" or > "don't use Docker". If Docker is providing meaningful enforcement and > limiting the access of the "contained" app to only the directory(ies) > you share with it in the container config (though not subject to the > host system's *permissions*) that's a very different proposition. > > Trusting *myself* not to abuse Docker's privilege-escalation abilities > (on a system where I already have root), checking carefully what paths > are shared via the container configs, and making sure that the path > containing those configs is never shared... That's within the realm of > reasonable expectations. > > > 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%. > > To be clear, I did not knowingly or explicitly do any of these things > except "download and run a containerized app". I downloaded the app as > a regular user, used my sudo powers to add said user to the docker group > (because all the "getting started" instructions just say that you need > to be in the docker group to use Docker) and ran, as a regular user, > "docker-compose -d up". Now that I know to go looking for it, I see > that the "volumes" directive appears in one of the config files. While > I acknowledge that the responsibility for understanding the tools I use > ultimately falls to me, nothing in this sequence jumps out to me as > "you are granting unrestricted root access!" or "you'd better trust > this app 100%". > I never used docker-compose, only the docker command itself, so I've always known more or less what was going on :) docker-compose is a layer on top of docker, so it hides things away from the user (in this case, the arguments for the docker command are in a config file apparently). So things are even less explicit, for the sake of simplicity. I think two important things are 1) *which user* is running in the container (root or non-root), and what volumes are shared. These are the arguments that you would use the most often with 'docker run', and also the king of things you'd want to check in a docker compose file. There are many ways to run container with docker, depending on the use-case. If you want to run a container manually, as your own user, and while sharing only the current directory, you can do this: sudo docker run -it --rm \ -u $(id -u):$(id -g) \ -v /etc/group:/etc/group:ro \ -v /etc/passwd:/etc/passwd:ro \ -v $(pwd):$(pwd) -w $(pwd) \ $YOUR_DOCKER_IMAGE Note that the two first -v arguments are optional, but they allow that you user id is known in the container. Try with and without, both work. This is a command that I use often, but when you get started with docker, it's unlikely you'll find that by yourself at the first try :) > > As a fairly experienced Debian user, I've been accustomed to add myself > to all sorts of groups over the years, and the only one that has ever > been presented as "this grants full root powers" is sudo, which then > pops up a stern warning the first time you use it. Also it's sudo. Its > singular, stated purpose is to grant root powers. The fact that no > warning popped up anywhere along the way to discovering that my > supposedly sandboxed Docker app was creating files as root on the host > strikes me as alarming. > > In my defence, I knew I was playing with things I didn't understand, so > the "regular user" in question was a fresh, blank account in a KVM > virtual machine that has no shared storage or memory. I'm not > *entirely* naive. That said, am I the only one who finds it worrying > how easy it would be for a moderately naive desktop user to unwittingly > grant a malicious containerized app root access to the entire > filesystem of their real system without doing anything obviously > reckless or stupid or encountering any warning along the way? Is this a > thing that can and should be addressed somehow? > I don't think there's anything I can do here. docker is a tool for admin and developers, ie. power users, so the assumption is that either they know, either they'll learn. Also it's not really a docker issue, from the moment you get code from the net (docker hub) and execute it, you must trust the source of the code. The big issue is that, indeed, it's not obvious that docker run as root, if ever you add yourself to the docker group. Maybe we could add a note in https://wiki.debian.org/Docker ? Do you want to do that? > > > > 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 :) > > If being aware of — and careful with — the "volume" directive is the > key to running Docker containerized apps in a reasonably safe way, I > think I won't mess around with the "just install the unstable package > and see if it works" approach. Maybe I'll wrap docker in a shell script > that greps the configs for the "volume" directive, lists the paths given > there, and gives me an "are you sure you want to do this" prompt, just > as a reminder in case I get careless. Possibly with an extra check to > call me rude names and abort if the directory containing the configs is > in any of those shared paths. ☺ > > Thanks for your informative response, and sorry if I hit the panic > button over nothing. > No worries at all ! Have a great day, Arnaud > > Cheers! > -Chris > > > > 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 > > > > >
