feat(sandbox): support file-level read_only overrides within read_write directories

[mjamiv]

Summary

When a file path is listed in filesystem_policy.read_only but its parent directory is listed in filesystem_policy.read_write, the file remains writable. The read_write rule on the parent takes precedence and the file-level read_only has no effect.

Use Case

We run an AI agent (OpenClaw) in an OpenShell sandbox. The agent's persona file (SOUL.md) lives inside the writable workspace directory (/sandbox). We need the agent to read this file at startup but never write to it — a prompt injection that rewrites the persona file can permanently alter the agent's behavior for all future users.

Today the only workaround is chmod 444, which is a soft guard since the sandbox user owns the file and can chmod it back.

Steps to Reproduce

Policy YAML:

filesystem_policy:
  include_workdir: true
  read_only:
    - /usr
    - /lib
    - /sandbox/.openclaw/workspace/SOUL.md   # <-- should be read-only
  read_write:
    - /sandbox                                # <-- parent is read-write
    - /tmp

landlock:
  compatibility: best_effort

After applying:

# Inside sandbox (running as 'sandbox' user):
head -1 /sandbox/.openclaw/workspace/SOUL.md   # ✅ read works
echo "injected" >> /sandbox/.openclaw/workspace/SOUL.md  # ❌ write succeeds (should fail)

Expected Behavior

A file-level read_only entry should override a directory-level read_write entry for that specific path. The more specific rule should win.

Root Cause

Linux Landlock rules are additive — you cannot restrict a child path more narrowly than a parent path at the kernel level. This means the fix needs to happen in OpenShell's policy layer. Possible approaches:

1. Restructure the Landlock ruleset: Instead of granting read_write on the entire /sandbox directory, grant read_write on subdirectories/files individually, excluding the read_only paths. This is more complex but stays within Landlock's design.

2. Supplement with file permissions: After applying the Landlock ruleset, chown root:root + chmod 444 the read_only files that fall inside read_write directories. This requires the sandbox setup to run as root before dropping privileges.

3. Use bind mounts: Bind-mount the read_only files from a read-only source, so the sandbox user cannot modify them even with ownership.

Environment

• OpenShell: v0.0.16
• Kernel: Linux 6.8.0-90-generic (Landlock ABI V4)
• Related closed issues: bug: Landlock ruleset abandoned entirely when a single path does not exist #664 (per-path error handling), sec(sandbox): BestEffort Landlock silently degrades to no filesystem sandbox #584 (silent degradation), sec(sandbox): upgrade Landlock ABI from V2 to highest available #593 (ABI upgrade)

Impact

This is a security gap for any deployment that needs fine-grained filesystem immutability within a writable sandbox workspace — particularly AI agent deployments where certain configuration or persona files must be tamper-proof.

[johntmyers]

Thanks for reporting. We're discussing internally. I don't think Option 1 would work, that would effectively make /sandbox non-writable since Landlock only covers paths existing at rule time.

[johntmyers]

After discussing we have decided we will not be supporting this. The current behavior is a Landlock security invariant which is operating as intended. We worry that adding standard Linux DAC workarounds would undermine the single-enforcement point we get with Landlock. I would suggest exploring if you can invert your approach (make a parent read_only and then allowlist specific read_write children) or split read/write directories as siblings vs ancestors. This also is a general improvement area for OpenClaw. If there are certain configurations that should not be writable by the agent itself, then they should support directory structures that fit within the abstractions provided by tools like Landlock. Standard Linux DAC isn't a good enough enforcement anyway.

[mjamiv]

Thanks for the detailed explanation @johntmyers. That makes sense, we'll look at restructuring our directory layout to work within the Landlock model. Appreciate the suggestion on inverting the approach.