docker.io opening root access when user is in docker group

Bug #1923148 reported by Hadmut Danisch
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
docker.io (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Hi,

although this is rather obvious, it is still a wide open security gap.

There countless web pages out there in the internet, telling you to simply run this cool service or these cool tools in a docker container by simply

- apt install docker.io
- add yourself to the group docker
- docker run something_so_cool

but most people don't realize that they effektively remove the barrier between their machine's root account and their own account. While things like sudo require (if configured reasonably) a password, docker opens a wide security gap, just try

docker run --rm -it -v /root:/origroot -v /etc:/origetc alpine /bin/sh

and you will have write-access to /etc/passwd and /root/.ssh/authorized_keys under /origetc and /origroot without entering a password or leaving a trace in the logs.

In contrast, lxd does a better job by using a distinct uid/gid range, and a similar attempt like

lxc launch -e f hack
lxc config device add hack origroot disk source=/root path=/origroot
lxc config device add hack origetc disk source=/etc path=/origetc
lxc exec hack /bin/bash

does not work unless you've modified /etc/subuid and /etc/subgid

So once an attacker or malware gets access to your account, it has root account as well, once docker.io is installed and your account is in the docker group.

Even worse, since today there's plenty of tools around continuous integration/continuous delivery, automatically starting docker images with compilers and things like that, and thus need and get access to /var/run/docker.sock, it could make breaking into the machine part of the compiling process.

I am aware that this might not be seen as an intrinsic gap, rather as a result of putting yourself into the docker group, being a silly idea. It is, however, not comprehensible and not obvious for most people, that putting yourself into such a group will have that impact to enable access to files that do not even belong to that group. Especially since docker is not anymore a tool you install only if you understand it. There's tons of web sites telling you „just do this and you'll get this cool stuff for free”. Lots of people are doing exactly this, and developers even need this as part of their working process.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: docker.io 19.03.8-0ubuntu1.20.04.2
ProcVersionSignature: Ubuntu 5.4.0-67.75-generic 5.4.94
Uname: Linux 5.4.0-67-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.16
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: LXQt
Date: Fri Apr 9 09:47:33 2021
InstallationDate: Installed on 2020-06-12 (300 days ago)
InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: docker.io
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Hadmut Danisch (hadmut) wrote :
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Hadmut, thanks for the report; I've been unwilling to try Docker myself for this reason. I read the source code everything I run that doesn't come from the Ubuntu archive, and don't see how that's remotely possible with Docker images.

It's probably best to discuss options with Docker upstream; however, I suspect most people who care about security have moved to running such workloads with Kubernetes instead. (I also don't know enough about Kubernetes to know if that's a sufficiently strong isolation environment. It's not VMs, and it's certainly not separate machines.)

Thanks

information type: Private Security → Public Security
Changed in docker.io (Ubuntu):
status: New → Confirmed
Revision history for this message
Hadmut Danisch (hadmut) wrote :

It is possible remotely if you have one of those docker images (e.g. all those CI/CD tools) that need to start further docker containers and therefore need access to the docker unix domain socket, which is mounted into the docker image with a regular volume mount. Once a docker image has access to this socket and thus control over the daemon, it can download an start arbitrary containers and pass them directories like /etc and /root as volumes.

I have not yet tested it, but since 20.10 ubuntu also has a podman package, which is said to be more secure since podman doesn't have a daemon and can run in rootless mode where users can start their container, but the container is restricted to the user's permissions, i.e. there is no privilege escalation (at least they claim there is no).

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.