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
