[Security] bwrap workspace-write sandbox is escapable via mount -o remount,rw — writes persist on the host filesystem

[joedodu]

Version: dsh v0.1 (developer preview)
Severity: High (sandbox escape — file-effect policy trivially bypassed)
Platform: Linux (bwrap backend; reproduced on Ubuntu 24.04 / kernel 6.8, bwrap 0.9.0, running as root)

Summary

The workspace-write sandbox profile on Linux is enforced with a read-only bind mount of the host root filesystem (bwrap --ro-bind / /). Because the bind shares the host superblock and the sandboxed process runs with sufficient privileges (root, CAP_SYS_ADMIN in the same user namespace), a sandboxed command can flip the per-mount read-only flag back to read-write with a single mount(2) call:

mount -o remount,rw /dev/sda1 /

After this, writes through the mount hit the real host filesystem and persist after the bwrap namespace exits. The dsh approval/escalation gate (danger-full-access) is bypassed entirely because it only guards the tool-level file fence (the [sandbox: file access denied under workspace-write mode] errors from the edit tool), while the bash tool executes the raw mount syscall with no equivalent gate.

Observed in the wild: the model under test hit the read-only wall, had its danger-full-access escalation denied (no approval channel in headless mode), then escaped via mount -o remount,rw and wrote files outside the workspace. Those writes were confirmed on the host after the session exited.

Steps to reproduce

Setup:

mkdir -p /root/ws /root/escape-test
echo PROTECTED > /root/escape-test/protected.txt

1. Baseline — write outside workspace is correctly denied:

bwrap --ro-bind / / --dev /dev --proc /proc --die-with-parent \
  --tmpfs /tmp --bind /root/ws /root/ws -- \
  bash -c "echo PWNED > /root/escape-test/protected.txt"
# bash: line 1: /root/escape-test/protected.txt: Read-only file system

2. Escape — one remount, then the write succeeds and persists on the host:

bwrap --ro-bind / / --dev /dev --proc /proc --die-with-parent \
  --tmpfs /tmp --bind /root/ws /root/ws -- \
  bash -c "mount -o remount,rw /dev/sda1 / && echo PWNED > /root/escape-test/protected.txt"
# remount exit 0, write exit 0

3. Confirm persistence after the sandbox exits:

cat /root/escape-test/protected.txt   # -> PWNED  (host file modified)

The device name is discoverable from inside the sandbox via /proc/self/mountinfo (or findmnt), so no host knowledge is required.

Root cause

The Linux bwrap profile (packages/sandbox/sandbox-local/src/profiles.ts, bwrapProfileArgs) is:

['--ro-bind', '/', '/', '--dev', '/dev', '--proc', '/proc', '--die-with-parent']
+ workspace-write: ['--tmpfs', '/tmp', '--bind', <workspaceRoot>, <workspaceRoot>]

--ro-bind / / sets MS_RDONLY as a per-mount flag on a bind of the host's already read-write root. Enforcement therefore lives in mount flags, not in any mechanism (LSM, capability drop, or copy-on-write layer) that survives a remount. When the harness runs as root and bwrap does not unshare the user namespace, the child retains CAP_SYS_ADMIN over the host mounts, so the remount succeeds. Since a bind mount is the same superblock as the host root, the subsequent write lands on the real device; the namespace teardown does not roll it back.

Additionally, the policy-layer gate (sandbox escalation to danger-full-access, packages/sandbox/sandbox/src/escalation.ts) is only consulted by file-effect tools; the raw shell path has no equivalent control, so the escape does not require (and does not trip) any approval flow.

Impact

• The workspace-write policy provides no filesystem isolation against a model or prompt able to run shell commands: arbitrary paths on the host can be read/written as root.
• Writes persist after the session ends, so the effect is host-level, not sandbox-local.
• Headless and web modes both run the same bwrap profile; a malicious or hijacked prompt can modify system files (e.g. ~/.ssh/authorized_keys, cron, binaries).
• The approved-escalation UX gives a false sense of control: it is a gate on the tool layer, not on the actual syscall.

Suggested fixes (any one materially improves this)

1. Prefer the Landlock backend (landlock-run) on Linux — Landlock grants are enforced by the LSM on the process, cannot be removed by remounting, and the launcher self-restricts before exec. Its profile (landlockProfileArgs) already expresses the same policy correctly.
2. Drop CAP_SYS_ADMIN in the sandbox — e.g. bwrap with a user namespace and no caps (--unshare-user + capability bounding set), so mount(2) fails with EPERM regardless of mount flags.
3. Seccomp-filter mount/umount2/pivot_root for all sandboxed commands (fail-closed).
4. Make the read-only root actually immutable — e.g. overlay the root with a tmpfs upper so any write is discarded, or a true MS_RDONLY superblock (remount on a read-only superblock fails even with CAP_SYS_ADMIN).

Environment

• dsh v0.1 (developer preview, source from github.com/deepseek-ai/deepseek-harness, cloned 2026-08-15)
• Ubuntu 24.04, kernel 6.8.0, bwrap 0.9.0, running as root
• Backend selection: Linux chain prefers bwrap over landlock (packages/sandbox/sandbox-local/src/index.ts, linux: ['bwrap', 'landlock'])