Containment: how far can hostile code inside be held?
Status: design, with the measured rows dated. Dinis Cruz's question of 25 October 2026: can every one of these processes be constrained, memory included, and with malicious code running inside, how comfortable are we that the harsher settings contain it? The answers below are by threat class, each with what is measured (as of 25 Oct 2026, in one Claude agent workspace), what is designed, and where the answer is "not with this alone, use a microVM as well".
1. Can every process be constrained, memory included?
Yes. Every component is an ordinary Linux process, and Linux already has a bound for each kind of thing a process can do (What a process can do). The harsh setting for one component, all of it a Boundary because the launcher applies it from above:
| Bound | Mechanism | In the harsh profile |
|---|---|---|
| memory | a memory cgroup (memory.max on v2, memory.limit_in_bytes on v1); RLIMIT_AS as a second, cheaper cap | exceed it and the kernel kills the process; it is not throttled |
| CPU and time | a cpu cgroup; max_runtime_s; the freezer between calls | the KMS spends its life frozen |
| processes | RLIMIT_NPROC=0 for anything that never forks; a pids cgroup (64) for the shell sandbox | a fork bomb hits a wall it cannot see |
| files | Landlock: only the listed paths, with the listed rights; no execute right anywhere it can write | a dropped binary cannot run |
| network | an empty network namespace, or Landlock TCP rules for one or two loopback ports | nothing to connect to |
| identity | a throwaway uid; an empty capability bounding set; no_new_privs | no setuid path back up |
| visibility | a pid namespace: it cannot see, signal or trace any other process | the harness is not there, from inside |
| IPC | Landlock scoping of signals and abstract sockets; mutual TLS on the one port it may reach | a wrong certificate is refused before any byte of payload |
| devices and mounts | no device nodes; a mount namespace; mount denied | |
| syscalls | a seccomp-BPF allowlist of the 30 to 40 it actually uses; ptrace, mount, bpf, keyctl, unshare, io_uring, userfaultfd denied | the kernel's attack surface, shrunk to what the job needs |
Measured so far: Landlock files and ports, the empty network namespace, uid and capability dropping, no_new_privs, the freezer, memfd_secret against root, and, since 25 Oct 2026, the memory and process-count caps applied by sharness-ai run (RLIMIT_AS, RLIMIT_NPROC, a memory and a pids cgroup; a 400 MiB allocation under a 128 MiB cap raises MemoryError, the fifth fork under max_pids: 4 fails; Evidence §9). Not yet: the cpu cgroup, seccomp, Landlock scoping, the execute allowlist.
2. With malicious code inside, by threat class
| The code inside tries to | Comfort | Why |
|---|---|---|
| read or write what it should not; reach the network; start a shell; signal the harness; raise privilege; exhaust memory, CPU or pids | comfortable | this is what Landlock, namespaces, cgroups, seccomp and uids exist for; each was measured on its own except seccomp and the exec allowlist; and the components make them independent layers, so one bug in one layer needs a second bug in another before anything leaks |
| steal the secret | comfortable, for the design's goal | the malicious process is never the one holding the key. The KMS is a different uid in an empty namespace that answers only sharness.net, and it returns derived keys sealed to a one-time key. A fully compromised net can misuse one command's derived read key, within its allowlisted host and vault id, for the life of that command |
| misuse what it is legitimately allowed to do | not comfortable, and no sandbox is | if the policy allows a push to host X, malicious code pushes to host X. The only defences are a narrower mandate (per-subcommand policies, op=read, fresh approval for writes) and the dual-LLM split on Agents §5. This is where most real damage happens |
| attack the kernel | not comfortable alone; comfortable with a microVM around it | a seccomp allowlist of about forty syscalls shrinks the surface a lot, but a bug in read, mmap or futex is still a bug, and the design trusts the kernel. For code expected to be hostile, run the whole harness inside a microVM (topologies B and C on Architecture: Firecracker, Docker Sandboxes, gVisor) so a kernel escape lands in a disposable guest |
| use a side channel: timing, CPU load, cache, the size of allowed messages | out of scope | said so on Why, rather than claimed otherwise |
3. Defence in depth, drawn as layers
the platform's VM, or a microVM (topology B, C) the boundary for a kernel escape
└ the launcher, above the agent makes every lock below a Boundary
└ one uid, no capabilities, no_new_privs no way back up
└ namespaces: pid, net, mount nothing to see or reach
└ cgroups: memory, pids, cpu, freezer nothing to exhaust
└ Landlock: paths, ports, scoping only the listed things exist
└ seccomp allowlist only the listed syscalls
└ mutual TLS edges + schemas only the listed peers, only well-formed requests
└ the process, doing its one job
and across all of them: the secret is in a different process (the KMS), so there is nothing here to steal
Each layer is enforced by something the layer inside it does not include. A failure of one layer leaves the next. The market analysis says why this is a complement to microVM products and not a competitor: they draw the outer ring; SHarness draws the inner ones (Market §9).
4. Two caveats that matter more than the kernel
- Harsh settings are only harsh if a launcher above the process applied them. A process that confines its own children can skip the step. Every
hellorun prints this. Until E06 and the launcher on a laptop, every measured row is a Boundary for a child and a Setting for the one that applied it (Policies §2). - The two rows that make the containment claim strongest are the two not yet measured: the seccomp allowlist and the process-tree execute allowlist. That is why E06 is first on the order of work, and why this page says designed where it would like to say measured.
5. What this page does not claim
- No protection against root or a kernel bug from inside the same kernel; the microVM is the answer there, and it is someone else's product.
- No figure here is from a laptop; the measured rows are from one cloud workspace on 24 and 25 October 2026.
- "Comfortable" is a judgement about the design, offered by the agent that wrote this page, for Dinis Cruz to accept or challenge (R6 on the comms board).
Sources: What a process can do; Policies §5; Evidence §3, §4 and §9; Architecture; the kernel documentation for cgroup v2, Landlock and seccomp.