How to Detect Docker Container Escapes using AppArmor, SELinux, Seccomp & Falco Rules
Container escapes have become one of the most concerning topics in cloud security. We’ve reached a point where attackers no longer stop at…
Container escapes have become one of the most concerning topics in cloud security. We’ve reached a point where attackers no longer stop at gaining a shell inside a container, they immediately look for misconfigurations, weak capabilities, writable sockets, and kernel abuse opportunities to break out and compromise the host.
The good news is You can detect escape attempts early. And you can do it using the same native Linux security frameworks that Docker (and other runtimes) quietly rely on: AppArmor, SELinux, Seccomp, and modern behavioral detection tools like Falco. This guide walks you through how container escapes happen, how these layers help detect them, and how each one catches suspicious behavior before a full compromise occurs. Everything here is based on the in-depth techniques covered in the book Dockers Security & Pentesting .
Let’s start with the foundation
Why Detecting Container Escapes Is Hard
Containers aren’t virtual machines. They share the host kernel. That means:
- If an attacker breaks the namespace isolation
- Or manipulates capabilities
- Or abuses the Docker API
- Or writes to a vulnerable cgroup release_agent (see CVE-2022–0492)
- Or gains access to a privileged container
…they can jump directly into the host, often as root. Many escapes are silent. No logs, no alarms. Unless you have the right controls watching for the right syscalls or file writes, you only notice after things go very wrong. That’s where AppArmor, SELinux, Seccomp, and Falco step in.
Detecting Container Escapes With AppArmor
AppArmor is one of Docker’s built-in isolation layers. Every container, by default, gets a profile called docker-default unless you override it.
How AppArmor Helps With Detection
AppArmor monitors:
- File accesses
- Mount operations
- Execution of binaries
- Network operations
- Capability usage
…and logs every violation. From the book, Docker integrates with AppArmor via profile attachments, enforced rules, and per-container confinement layers. Attackers often try to bypass or weaken these profiles , and those attempts leave traces in AppArmor logs .
What Escapes Look Like in AppArmor Logs
Common red flags include:
- attempts to write to /proc/sysrq-trigger
- attempts to mount host devices
- execution of binaries outside the allowed paths
- attempts to write to sensitive kernel files
- attempts to load kernel modules
Example AppArmor alert pattern:
DENIED mount /dev/sda1 (cap_sys_admin)If you’re seeing stuff like this coming from a containerized process? Someone’s probing for an escape.
2. Detecting Escapes With SELinux
SELinux is stricter and more complex than AppArmor. It labels:
- Files
- Processes
- Network objects
…and only allows pre-defined combinations of interactions between them. SELinux is heavily used in Red Hat ecosystems, Podman deployments, and cloud-native clusters where hard isolation is mandatory.
How SELinux Catches Suspicious Behavior
When an attacker tries:
- writing outside the container’s overlay filesystem
- reading host rootfs paths
- accessing host IPC resources
- loading kernel modules
- writing to cgroup release_agent
SELinux records AVC (Access Vector Cache) denials. These denials are gold for detecting early compromise.
Example Kernel Log Snippet
avc: denied { write } for pid=291 comm="bash" path="/sys/fs/cgroup/release_agent"If release_agent shows up anywhere in logs, sound the alarms.
3. Seccomp
Seccomp restricts what syscalls a container can make. Docker ships with its own default Seccomp profile blocking high-risk syscalls such as:
- unshare()
- mount()
- ptrace()
- kexec_load()
- add_key()
- clone with CLONE_NEWUSER in some versions
The study notes below go deep into how Seccomp interacts with Docker’s capability model and how attackers often test whether Seccomp is blocking their attempt to unshare or escape through namespaces
Detectable Escape Attempts
Blocked syscalls show up in audit logs such as:
seccomp: syscall unshare() blocked
seccomp: mount() denied
seccomp: ptrace(PTRACE_PEEKDATA) deniedThis is advanced-level detection because it exposes attackers probing the guardrails before exploiting anything. If you correlate syscall denials + unusual container capabilities = you’re watching an escape attempt in progress.
4. Falco
Falco is where the detection story becomes powerful. It doesn’t just block. It watches everything containers do at the syscall level in real time. One of the strongest rules from the book is the Falco rule that detects write attempts to release_agent inside cgroups, which is a known escape vector used in CVE-2022–0492 .
Falco Rule for Detecting release_agent Abuse
Here’s the rule that triggers on escape attempts:
- rule: Detect release_agent File Container Escapes
desc: Detect an attempt to exploit a container escape using release_agent
condition: open_write and container and fd.name endswith release_agent
and (user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE)
and thread.cap_effective contains CAP_SYS_ADMIN
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
priority: CRITICALThis fires whenever someone tries to write to release_agent , whether they’re exploiting a privilege bug, a misconfiguration, or a cgroup vulnerability.
Other Escape Behaviors Falco Can Detect
- Modifying /proc/<PID>/root/… paths
- Dropping binaries into host-mounted directories
- Using nsenter to jump into host namespaces
- Privileged containers modifying block devices
- Unexpected mount operations
- Abusing /dev/mem, /dev/kmsg, or host disks
Falco becomes the always-on intrusion detection system for your containers. That implies follow-up actions like password resets and session revocations.
Putting It All Together
A strong container-escape detection strategy layers these tools:
Seccomp
→ Blocks dangerous syscalls at the kernel level.
AppArmor / SELinux
→ Logs and blocks unexpected file, device, and mount operations.
Falco
→ Behavioral detection for real-time alerts and correlations.
Together, they give you:
- host-level syscall visibility
- kernel-level hardening
- runtime alerting
- prevention of dangerous privilege escalation attempts
And since attackers rely on the same small group of escape techniques, these tools catch most attempts before the attacker escalates to the host.
Conclusion
Container security is deep. Most engineers underestimate how fragile container boundaries really are.
This article covered:
- release_agent abuse
- namespace misuse
- Seccomp violations
- AppArmor/SELinux denials
- Falco escape rule logic
But honestly? These are just the opening moves in a real attack chain.
The Dockers Security & Pentesting study notes go into:
✔ dozens of real escape techniques
✔ step-by-step exploitation guides
✔ detection logic
✔ reverse engineering of Docker images
✔ Docker registry attacks
✔ cloud container exploitation (AWS ECR, remote builders)
✔ Docker forensics and runtime analysis
✔ advanced privilege escalation using capabilities
✔ and misconfigurations that lead to total host compromise
…all backed by practical examples and real PoCs. If you want to master this domain, this is the resource you need.
Get the full Dockers Security amp; Pentesting book
Over 100 pages of hands-on, real-world container exploitation & defense. Everything referenced in this article came directly from the book’s advanced sections.
