-
Notifications
You must be signed in to change notification settings - Fork 762
Add sandlock as a kernel-level LocalSandbox backend on Linux #2035
Description
The Sandbox abstraction in #1968 is a great design -- decoupling tool logic from execution environment. The proposed LocalSandbox runs commands via native subprocess with no kernel-level isolation, which means LLM-generated code has full host access (filesystem, network, env vars).
sandlock could serve as a hardened LocalSandbox implementation that enforces isolation at the kernel level via Landlock + seccomp-bpf, without requiring Docker or cloud infrastructure:
from sandlock import Sandbox, Policy
policy = Policy(
fs_readable=["/usr", "/lib", "/lib64", "/etc"],
fs_writable=[workspace_dir],
net_allow_hosts=[], # no network by default
max_memory="512M",
max_processes=10,
)
result = Sandbox(policy).run(["python3", "-c", code], timeout=30)
# result.stdout, result.stderr, result.exit_codeThis fits the Sandbox ABC from #1968 -- execute_code, read_file, write_file, list_files all work within the sandlock policy's filesystem allowlist.
| LocalSandbox (current) | SandlockSandbox | DockerSandbox | |
|---|---|---|---|
| Isolation | None | Kernel-enforced (Landlock+seccomp) | Container |
| Startup | ~0ms | ~5ms | ~200ms+ |
| Setup | None | pip install sandlock |
Docker daemon |
| Network control | No | Domain-level allowlist | Network namespace |
| Resource limits | No | Memory, CPU, process, fd limits | cgroups |
| Platform | Any | Linux 6.12+ | Any with Docker |
Tradeoff: Linux-only. Non-Linux users would continue using Docker or the unsandboxed local backend.
Timing-wise, since the Sandbox abstraction is being designed right now, it might be worth considering what the interface needs to support kernel-level backends like this. Happy to help with integration.
Disclaimer: I'm the sandlock author.