The author’s goal was to explore container isolation by writing a small program that runs a shell in an isolated environment using only the minimum set of Linux kernel mechanisms. The program, contained.c, uses clone with namespace flags to create separate mount, PID, IPC, network, and UTS namespaces, and optionally a user namespace for UID/GID mapping. After creating the child process, the code drops most capabilities, installs a seccomp filter to allow only a handful of system calls, and constrains resources via cgroups (memory, CPU, pids, block I/O) and the older setrlimit interface. It also prepares a fresh mount namespace, binds a temporary directory, and pivots root to that directory before executing the requested command.
The mechanism relies on several complementary Linux features: namespaces isolate kernel objects such as the filesystem and process table; capabilities subdivide root privileges so the program can drop dangerous ones; seccomp filters restrict which system calls the child may invoke; cgroups and setrlimit limit resource usage such as memory and CPU; and mount namespaces combined with pivot_root change the child’s view of the root filesystem. The author notes that the program is intentionally minimal and does not aim to produce a secure sandbox, but rather to demonstrate which permissions are categorically unsafe for untrusted code.
The author cautions that this exercise is not a secure boundary; user namespaces, while useful for mapping IDs, are off by default in mainstream kernels and have historically been a source of privilege‑escalation bugs. The final program totals roughly 570 lines, slightly above the original 500‑line target, illustrating that containers are essentially thin wrappers around existing kernel features rather than complex new abstractions. This serves as a reminder that real container runtimes layer additional safety mechanisms on top of these same primitives.