Sandbox Image Hardening#
The NemoClaw sandbox image applies several security measures to reduce attack surface and limit the blast radius of untrusted workloads.
Removed Unnecessary Tools#
Build toolchains (gcc, g++, make) and network probes (netcat) are
explicitly purged from the runtime image. These tools are not needed at runtime
and would unnecessarily widen the attack surface.
The runtime image keeps a small set of operational utilities for normal sandbox
workflows, including vi, jq, and dos2unix. Use these for lightweight
inspection and file cleanup inside the sandbox, but make durable image or policy
changes in the NemoClaw source tree and rebuild the sandbox.
If you need a compiler during build, use the existing multi-stage build
(the builder stage has full Node.js tooling) and copy only artifacts into the
runtime stage.
Process Limits#
The container ENTRYPOINT sets ulimit -u 512 to cap the number of processes
a sandbox user can spawn. This mitigates fork-bomb attacks. The startup script
(nemoclaw-start.sh) applies the same limit.
Adjust the value via the --ulimit nproc=512:512 flag if launching with
docker run directly.
Dropping Linux Capabilities#
The NemoClaw entrypoint drops dangerous capabilities from the process bounding
set before it starts agent services.
It removes CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_NET_RAW,
CAP_DAC_OVERRIDE, CAP_SYS_CHROOT, CAP_FSETID, CAP_SETFCAP,
CAP_MKNOD, CAP_AUDIT_WRITE, and CAP_NET_BIND_SERVICE.
When setpriv is available, the entrypoint also removes the remaining
privilege-separation capabilities during the switch from root to the
sandbox and gateway users.
For defense-in-depth, also drop all Linux capabilities at the container runtime when you launch the image directly:
$ docker run --rm \
--cap-drop=ALL \
--ulimit nproc=512:512 \
nemoclaw-sandbox
Docker Compose Example#
services:
nemoclaw-sandbox:
image: nemoclaw-sandbox:latest
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE
ulimits:
nproc:
soft: 512
hard: 512
security_opt:
- no-new-privileges:true
read_only: true
tmpfs:
- /tmp:size=64m
Note: The
Dockerfileitself cannot enforce--cap-drop. That is a runtime concern controlled by the container orchestrator. Always configure capability dropping in yourdocker runflags, Compose file, or KubernetessecurityContext.
Filesystem Layout#
The sandbox Landlock policy declares which paths are writable.
The agent’s home directory (/sandbox) is writable by default:
Path |
Access |
Purpose |
|---|---|---|
|
read-write |
Home directory — agents can create files and use standard home paths |
|
read-write |
Agent config, state, workspace, plugins |
|
read-write |
Plugin state and config; blueprints within are DAC-protected (root-owned) |
|
read-write |
Temporary files and logs |
This writable default is intentional.
Seeing the sandbox user create files under /sandbox or /sandbox/.openclaw in a fresh sandbox does not mean Landlock failed.
Landlock still enforces the fixed read-only system paths below.
System paths remain read-only to prevent agents from:
Replacing system binaries with trojanized versions
Modifying DNS resolution or TLS trust stores
Tampering with libraries or shell configuration outside
/sandbox
The image build pre-creates shell init files .bashrc and .profile.
These files source runtime proxy configuration from /tmp/nemoclaw-proxy-env.sh.
Landlock Kernel Requirements#
Landlock LSM requires Linux kernel 5.13 or later with CONFIG_SECURITY_LANDLOCK=y.
The NemoClaw sandbox policy uses compatibility: best_effort, which means Landlock enforcement is silently skipped on kernels that do not support it.
On such kernels, protection falls back to DAC (file ownership and permissions) only. Files outside the writable paths would be inaccessible to the agent regardless of DAC permissions.
Operators should verify Landlock availability:
$ ls /sys/kernel/security/landlock
For production deployments, kernel 5.13+ with Landlock enabled is strongly recommended.
The test/e2e/e2e-cloud-experimental/checks/04-landlock-readonly.sh script validates enforcement at runtime.