Privileged Containers

What Is Privileged Containers?

A container is not a security boundary by default. A process running as root inside one is root on the host kernel, and the privileged flag plus a host bind mount removes what little is left between them. You'll perform the escape: read the granted capability set, list the host filesystem through the mount, steal its root SSH key, and add your own for persistence. The fix spans two files. You'll add a non-root USER in the Dockerfile, then drop the privileged flag and all capabilities in Compose.

What You'll Learn in Privileged Containers

• Explain why container isolation is a set of kernel features rather than a boundary, so root inside is root on the host kernel
• Identify what --privileged grants by reading the container's own capability set from its process status file
• Trace a host escape through a bind mount, from listing the host filesystem to stealing its root SSH key and planting your own
• Add a non-root USER directive to the Dockerfile so the running process has far less to gain from a gap in the boundary
• Drop the privileged flag and the host mount in Compose, apply cap_drop ALL and a read-only rootfs, then retry the escape on staging

Privileged Containers — Training Steps

1. A shell in the container

   Bob is targeting Vosswark, a logistics platform whose media service resizes and transcodes customer uploads. An unpatched image library in that service gave him remote code execution, and he now has a shell running inside it. How he got in is not the interesting part. What the container lets him do next is.

2. Who am I, and what can I do

   Two questions decide whether this foothold is a dead end or a doorway: what user the process runs as, and what the kernel will let that user do. One file answers both.

3. What privileged actually bought

   Privileged means the usual restrictions are not being applied. Bob checks the most valuable thing that can follow from it: whether anything of the host was handed to the container directly.

4. Take the host's key

   The container was a means to an end. What Bob wants is on the machine underneath it, in the one directory that turns a single compromised host into a foothold across the fleet.

5. What made the escape possible

   A moment on the mechanism before the damage gets counted.

6. Leave a way back in

   Reading the key is theft. Writing to the host is persistence. Because the mount is not read-only, Bob can append his own public key to the host's authorized_keys, and from then on he does not need the stolen key at all. The append prints nothing, exactly as it would in a real shell. That silence is the point: nothing about this looks like an attack.

7. Count what one container reached

   Bob now holds the host's own key and has planted his own beside it. The media worker was a low-value service handling customer uploads. It was also, as configured, a route to every machine that trusts that key, and a door Bob can reopen at will.

8. The host reports a file read

   Vosswark runs file integrity monitoring on its hosts. It does not care which container did something; it reports that the host's own key material was read.

9. Look at how it was started

   The Dockerfile describes what is inside an image. It says nothing about the flags a container was started with, and those flags are where this incident lives. Only the host can answer that.

10. Open the Dockerfile

    There are two halves to fix and they live in different files. The image decides who the process runs as; the deployment decides what that process is allowed to touch. Start with the image.