A common misconception is that Docker containers are sandboxes. They are not. They share the same Kernel as the host. If you are root inside the container, you are (technically) root on the host, hindered only by Namespaces and Cgroups.
The --privileged Flag
Developers often use `docker run --privileged` to fix permission errors.
This is a disaster.
It grants the container access to all host devices (`/dev/*`).
The Attack:
1. In the container, mount the host's hard drive: `mount /dev/sda1 /mnt`.
2. Browse `/mnt/etc/shadow`.
3. Change the root password. You now own the host server.
1. Docker Socket Mounting
If you mount `/var/run/docker.sock` inside a container (often done for "Docker-in-Docker" CI/CD pipelines), you give the container full control over the Docker daemon.
The container can simply tell Docker: "Please start a new container with access to the host filesystem."
It's trivial privilege escalation.
2. Dirty COW / Kernel Exploits
Because the kernel is shared, a kernel vulnerability (like Dirty COW) executed inside the container can crash or compromise the host kernel.
This is why high-security environments use gVisor or Kata Containers (which use real lightweight VMs).