[SECURITY] No read-only root filesystem — writable /sandbox increases attack surface

[h-network]

Problem Statement

The NemoClaw sandbox has a fully writable /sandbox and /tmp directory. While OpenShell Landlock policies restrict access to specific paths, the writable nature of the sandbox filesystem means:

1. Agents can create files anywhere within /sandbox
2. Agents can modify their own runtime environment
3. Persistent malware can survive within the writable filesystem

Impact

A compromised agent can:

• Write scripts and execute them later
• Modify runtime libraries or configuration within writable paths
• Create hidden files that persist across agent invocations
• Use writable space for data staging before exfiltration

Proposed Design

Support a read-only root filesystem mode with explicit writable overlays:

# docker-compose.yml
services:
  sandbox:
    read_only: true
    tmpfs:
      - /tmp:size=100M
    volumes:
      - sandbox-work:/sandbox/workspace:rw  # only workspace is writable

This limits the writable surface to explicitly declared directories. Combined with Landlock policies, this provides defense-in-depth.

References

• CIS Docker Benchmark 5.12: "Mount container's root filesystem as read only"
• Kubernetes Security Best Practices: readOnlyRootFilesystem

Alternatives Considered

No response

Category

enhancement: feature

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request

[wscurran]

✨ Thanks for submitting this issue with a detailed analysis, it addresses a security concern that could increase the attack surface of the sandbox, which could improve the security of NemoClaw.

---

Possibly related open PRs:
#871 security: enforce process limit to prevent fork bombs in sandbox,
#611 security: remove telegram and discord from baseline sandbox policy,
#379 fix(telegram): read model from sandbox registry instead of hardcoding