Harden sandbox against agent config tampering (defense-in-depth)

[ericksoa]

Context

#514 locks openclaw.json with filesystem permissions after startup. This issue tracks the remaining defense-in-depth measures to further harden the sandbox against agent self-modification attacks.

Hardening items

1. Tool policy deny list

Add .openclaw/openclaw.json and gateway restart commands (e.g. openclaw gateway run, kill) to SandboxToolPolicy.deny for the write, edit, and exec tools. This provides a software-level control independent of filesystem permissions.

2. Move config outside writable zone

Mount openclaw.json under a read_only path (e.g. /etc/openclaw/) instead of /sandbox/.openclaw/. This ensures the sandbox filesystem policy itself prevents writes, rather than relying on Unix permissions alone.

3. Enforce Landlock (drop best_effort)

Change landlock.compatibility from best_effort to enforce in nemoclaw-blueprint/policies/openclaw-sandbox.yaml. Audit for any functionality that breaks under strict enforcement.

4. Re-evaluate dangerous auth defaults

scripts/nemoclaw-start.sh sets allowInsecureAuth: True and dangerouslyDisableDeviceAuth: True in the gateway config. Evaluate whether these can be removed or scoped more narrowly (e.g. only in local development mode, not when CHAT_UI_URL points to a remote origin).

5. Lock parent directory

After #514's file-level lock, the agent can still delete openclaw.json from the parent directory if /sandbox/.openclaw/ is writable. Consider locking the directory to root:root 555 while keeping subdirectories (e.g. agents/) writable, or restructuring the directory layout.

Priority

Items 1-2 provide the strongest additional protection. Items 3-5 are incremental hardening.

[BenediktSchackenberg]

opened #654 for this — covers items 1 (tool policy deny list), 2 (config moved to /etc/openclaw/), and 5 (parent dir locked down).

items 3 (landlock enforce) and 4 (auth defaults) are documented as TODOs but not implemented yet. landlock enforce needs way more testing before we flip it, and auth defaults need a broader discussion about what the production story should look like.

builds on top of the permission fix from #514.

[cluster2600]

Verified on a live sandbox (openshell 0.0.14, base image) — rm -rf /sandbox/.openclaw succeeds despite the sticky bit on the parent directory.

The sticky bit prevents unprivileged users from deleting files owned by other users inside a directory, but it doesn't prevent deleting the directory itself if the parent (/sandbox) is writable by the sandbox user. Since /sandbox is in the read_write Landlock policy, the sandbox user can remove .openclaw entirely.

On the OpenClaw image with the immutability fix (#588), the files inside are root-owned so the sticky bit does protect them individually — but the directory structure itself can still be removed if the parent allows it.

Reproduction:

$ id
uid=998(sandbox) gid=998(sandbox) groups=998(sandbox)
$ rm -rf /sandbox/.openclaw
$ echo $?
0

Suggestion: add /sandbox/.openclaw to the Landlock read_only list so the kernel prevents any modification, regardless of DAC permissions.

[BenediktSchackenberg]

Hey — picked up on cluster2600's finding here. Added /sandbox/.openclaw to the Landlock read_only list in the sandbox policy so the agent can't nuke its own config even though /sandbox is writable. Fix is in PR #654.