Privileged Containers

What Is Privileged Containers?

A container is not a security boundary by default. A process running as root inside a container is root on the host kernel, and a privileged container with a host mount can write anywhere on the machine it runs on. This exercise covers a container escape: watch an attacker turn code execution inside a container into control of the host, then work the real fix with a non-root user, dropped capabilities, and a read-only root filesystem.

What You'll Learn in Privileged Containers

• Container isolation is a set of kernel features, not a boundary. Root in the container is root on the host kernel, so any gap in that isolation is immediately exploitable.
• Effectively all capabilities and access to host devices, which removes most of what separates the container from the host.
• Run as a non-root user, drop capabilities, and stop passing --privileged and the host mount.
• An attacker who lands code execution cannot write tools or persistence into the container, so the foothold is much harder to build on.

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.