Executive summary
compartment is a Linux process-isolation toolkit organized around two small C executables and one profile format. The rootless path combines Landlock, seccomp, environment cleanup, and audit logging. The root path adds Linux namespaces, pivot_root, capability handling, and a minimal container view. An optional BPF-LSM module can seal individual inodes at the kernel layer. The repository is unusually direct about its limits: it is a defense-in-depth tool, not a professionally evaluated security product or a complete boundary against every bypass class.
Problem and context
Running an AI agent, network client, or other complex process often gives one program access to both sensitive files and network egress. compartment makes those authorities explicit and supports splitting them between processes. Its worked SSH example gives one component read access to keys without filesystem writes and gives a second component network access without access to those keys.
What was built
| Component | Role |
|---|---|
compartment-user | Rootless Landlock and seccomp sandbox with environment and audit controls |
compartment-root | Namespace container with pivot_root, capability drop, and the same policy surface |
sandbox.sh | User and network namespace wrapper with a constrained proxy bridge |
compartment-bpf | Optional BPF-LSM inode sealing for advanced deployments |
The repository also includes profiles for AI agents, SSH, proxy helpers, containers, and relaxed development, plus a syscall profiler that can observe a program and draft a starting policy.
How it works
The rootless tool applies no_new_privs, filesystem rules, syscall filtering, environment sanitization, and logging before replacing itself with the target process. Child processes inherit restrictions and cannot remove them. The root tool builds a separate namespace environment and replaces the visible root filesystem rather than relying on chroot alone.
The optional BPF module is intentionally separate because it changes kernel, toolchain, and privilege requirements. It complements rather than replaces the zero-dependency core.
Evidence and validation
The v1.4.1 core separates unprivileged integration suites from real-root container and limited-root SSH suites. Their counts come from the runner; the documentation does not promise one fixed total. Profile loading now checks source trust, applies changes transactionally, and allows security switches to tighten policy only. Per-file and TCP-port Landlock rules extend the policy surface.
The BPF v0.8.0 documentation records 3,284 enforcement trials, 44 bypass scenarios, 17 strict-launch witnesses, and stress gates on kernels 6.8.0-139 and 7.0.0-31. Mount, ACL, and ioctl coverage were extended; timestamp writes are now in the no-chmod class. Opt-in self-protection has explicit operational costs and residual limits. These are recorded project results, not fresh kernel test runs from this portfolio review.
Boundaries
The repository does not claim formal verification, penetration testing, or complete bypass coverage. Kernel configuration and Landlock ABI support affect the protection available. Direct network-egress bypass coverage remains incomplete. The v1.4.1 documentation makes clear that allowing the dynamic loader can bypass an exec-target allowlist; even a closed exec-target boundary does not prevent an allowed program from interpreting or loading other code. The login-shell replacement is an opinionated deployment with documented compatibility and bypass caveats.
Repository map and first run
make
make test
./compartment-user --dry-run -- /bin/sh
./compartment-user -- /bin/shRead HOWTO.md for profiles and operational modes, DESIGN.md for the architecture and review log, and SECURITY.md for disclosure scope and known limitations. The optional BPF component has its own on-ramp and requirements.