A practical reference for understanding how Linux containers work, how they're isolated, and how those isolation boundaries get broken — the offensive security perspective.
Born from a Black Hat training masterclass: Offensive Container Security — A Masterclass in Breaking the Boundaries.
Two companion documents — read them together:
| Document | Purpose |
|---|---|
| Descriptive_Notes.md | The why. Deep explanations of how containers work (namespaces, cgroups, capabilities, seccomp, AppArmor, OverlayFS, networking) and why each attack succeeds. Read this to build the mental model. |
| Cheat_Sheet.md | The how. Commands, quick lookups, and step-by-step attack/defense playbooks. Search this during hands-on work. |
Both cover:
- Fundamentals: what a container actually is (not a VM), the container stack (runc/containerd/OCI), the two-questions framework (can I see it / can I touch it), the
/procleak channel - The isolation layers: namespaces, cgroups, capabilities, seccomp, AppArmor/LSM
- The attack surface: container escapes (misconfig, socket, capability, kernel), memory reading, deleted-file recovery, namespace tricks, network MITM
- Defense in depth: the three gates, the "enumerating badness always fails" meta-lesson, hardening checklists
A container is one process the kernel isolates with namespaces (what it sees) and cgroups (what it uses). Everything it holds still leaks through
/proc/<pid>/, and reaching it depends on two separate permissions — can I see it (namespaces) and can I touch it (capabilities). Isolation is layered, and every layer you remove makes the next one load-bearing.
| Lab | Wall | Bypass | Lesson |
|---|---|---|---|
| Seccomp Hunt (O) | Denylist of syscalls | io_uring (unlisted syscall) | Allowlist, don't denylist |
| Ghost Container (A) | Mount namespace | nsenter / /proc/<pid>/root/ |
Visibility is per-namespace |
| Death by Caps (C) | Capabilities | CAP_SYS_ADMIN + CAP_MKNOD |
Don't over-grant caps |
| Naked Emperor (H) | CAP_MKNOD dropped |
modprobe_path kernel primitive |
Block the capability, not instances |
| Pattern of Betrayal (J) | Same setup as H | core_pattern kernel primitive (|) |
Same family — recognize the pattern |
| Masked Binary (F) | AppArmor path rule | New binary, new path | Block actions, not paths |
| The Tap (E) | Network isolation | ARP spoofing | ARP has no auth; use TLS |
| Peeping Tom | Process isolation | --pid=host + CAP_SYS_PTRACE |
Memory-only ≠ safe; /proc leaks RAM |
| Operation Matryoshka (Z) | All of the above | SSRF → RCE → docker.sock → host root | Every flag was a misconfiguration |
The meta-principle: enumerating badness always fails. Whether it's a seccomp denylist, an AppArmor path rule, or an over-granted capability — the attacker finds a different instance that does the same action. Real security gates the capability and layers defenses so one failure isn't catastrophic.
- Basic Linux command-line comfort
- Familiarity with Docker (you've run containers before)
- Conceptual understanding of what a syscall is
You don't need to be a kernel expert — the notes build the mental model from the ground up.
Container security sits at the intersection of three skill layers (Linux internals → how containers work → offensive security). The Descriptive Notes include a curated resource list for each layer, but the single highest-ROI starting point is:
- "Container Security" by Liz Rice (~150 pages, fills the gap between "I know Linux" and "I understand escapes")
- "How Linux Works" by Brian Ward (the Linux internals you'll keep needing: devices, filesystems, networking)
This material is for educational purposes and authorized security testing only. The techniques described should only be used in lab environments, CTF challenges, or systems you own or have explicit permission to test.
MIT — feel free to use, share, and adapt.