CONTAINER RUNTIME BOUNDARIES
A technical research project I developed in industry: examining the boundary between runC’s read-only protection and the shared kernel, then studying constrained ELF file injection that preserves the original program flow.
KCon 2022 · Original talk title · Source withheld due to attack impact
Bonan Ruan · NSFOCUS Nebula Lab
Beijing · Technical talk
Runtime–kernel trust boundary
Based on published materials
Two questions guide the study: what does read-only protection trust, and can altered file content coexist with the runtime’s original behavior?
01 / OBJECT IDENTITY
runC enters container namespaces during initialization. With the required permissions, a /proc executable magic link can refer to a file object outside the namespace. Hidden paths do not necessarily mean unreachable objects.
02 / PROTECTION ASSUMPTION
The 2019 repair used a read-only bind mount to block ordinary writes while reducing copy costs. Dirty Pipe in 2022 changed kernel page-cache content outside that protection. It did not require the old runC vulnerability to remain unpatched.
03 / ENGINEERING CONSTRAINT
Replacing the binary destroys normal runtime behavior. The study instead used static ELF file injection under file-size, space, and PIE / ASLR constraints, returning execution to the original entry point.
Sources: write-up §§2 and 4; slides pp. 6–14 and 19–25. The following models describe the historical mechanisms studied in 2022, without inferring the state of current runC releases. WP ↗
Choose a runtime protection and a write condition. Trace the object being referenced, the layer that blocks changes, and whether the host file remains in the path.
CONTAINER
Executable on a read-only mount
Separate from the host file
HOST
The read-only mount refers to the same host runC file object
Same file object
Choose the protection and condition, then trace the file reference across the container boundary.
WHERE PROTECTION APPLIES
Read-only restrictions change access policy without necessarily creating a separate file copy. Advance the flow to compare this boundary with memfd.
Sources: WP §2.3 and slides pp. 12–14. The memfd design copies and seals the executable; the read-only design retains the same object. The 2019 discussion explains the cost and compatibility trade-off. A sealed copy isolates the host original in this study’s scope, without implying protection from arbitrary kernel flaws.
The refinement preserves runC rather than replacing it: redirect the entry within constrained space, then restore the original flow. Normal behavior does not prove file integrity.
The original entry leads directly into runC’s existing logic.
STATIC FILE INJECTION / STUDY MODEL
This diagram shows file structure and control flow. The study modifies an ELF file before execution, rather than injecting memory into a running process.
Dirty Pipe cannot grow a file or begin an overwrite at a page boundary. PIE / ASLR changes load addresses, so returning to the original entry must account for runtime address relationships. The diagram omits payloads, offsets, and exploit implementation.
Documents the historical space constraint. Payload content is not provided here.
The tested build had enough space for that length, based on its specific section layout.
Too small for the same placement. The study examined another region and tested subsequent behavior in that sample.
Sources: WP §§4.2–4.3; slides pp. 20–25. Byte counts describe particular historical builds and the implementation, rather than success rates, performance results, or cross-version guarantees. Layout compatibility requires per-build verification. Slides ↗ · Original Dirty Pipe analysis ↗
A compromised workload and an image-based path have different timing constraints. Compare their prerequisites, reported demonstrations, and points for defensive observation.
With execution inside a container, the historical scenario examines process and file references when the runtime enters that container again.
Slides pp. 16, 26 · WP §3.1, demonstration 1 ↗
DEVELOPMENT
Workload security and least privilege influence initial access. The article recommends rootless operation where feasible to reduce privileges available to later exploitation.
DEPENDENCIES
The article recommends image scanning and allowlists. Runtime build and loading conditions matter; image deployments do not all fit the same scenario.
RUNTIME
Update the kernel and runtime; monitor host runC changes and anomalous processes. Successful container startup alone does not establish runtime file integrity.
Scenarios and demonstrations: WP §3.1 and §4 “Effect testing”; slides pp. 16, 26–27. Defensive recommendations: WP §5 and slides pp. 31–32, presented in the context of the original study.
An industry research talk at KCon 2022. The write-up records protection designs, ELF file-injection constraints, and demonstrations in two scenarios. The study had no separate project name; this exhibit uses the original talk title.
I did not release the research source code because of its attack impact. These original diagrams explain the published mechanisms, preserving the study’s prerequisites and scope.