Isolation tier
Faber’s sandbox is kernel-shared isolation, the class of a hardened container. Every task runs on the host’s Linux kernel, behind namespaces, cgroups, seccomp, rlimits and an unprivileged identity.
What that means
Section titled “What that means”It does contain ordinary hostile programs: code that tries to read files it should not, reach the network, fork-bomb, exhaust memory or output, escalate privileges with setuid binaries, signal other processes, or persist after the request. Each of those is covered by an executable test.
It does not protect against a vulnerability in the Linux kernel itself. A
task can make system calls (fewer under the v2 allowlists and fewer still
under native_v2), and a kernel bug reachable through one of them can give
the attacker the host. Microarchitectural side channels are also out of scope.
And the Faber container is privileged: it holds the capabilities it needs to build sandboxes. A sandbox escape is a compromise of the host, not just of a container.
Deploying for your trust level
Section titled “Deploying for your trust level”| Who submits code | Recommended deployment |
|---|---|
| Your own team, CI jobs | One Faber host or VM. The defaults are fine |
| Authenticated users you can identify and ban (students, contest participants, customers) | A host or VM dedicated to Faber, nothing else of value on it, kernel kept patched |
| Anonymous or public users | Faber inside a VM per trust domain. The VM is the security boundary; Faber bounds resource use and keeps tasks apart within it |
| Mutually hostile tenants | A separate VM (and Faber) per tenant. Faber has one API key scope and does not separate tenants |
In every case:
- Give Faber a machine of its own. Do not co-locate it with databases, secrets or services the sandboxed code must never reach. In Kubernetes, use dedicated nodes.
- Keep the host kernel patched. Kernel vulnerabilities are the residual risk.
- Keep the API key on your servers. Every key holder can run code and read every stored file. Authenticate end users in your own service.
- Use the narrowest profile. Run compiled submissions under
native_v2.
Stronger backends
Section titled “Stronger backends”A gVisor or microVM (Firecracker) backend, with a much smaller host kernel surface, is on the roadmap behind the same API. Until it exists, the VM around Faber is the boundary for hostile public workloads.
If you suspect an escape
Section titled “If you suspect an escape”Treat the host as compromised. The runbook lists the steps.