sec(sandbox): seccomp filter allows dangerous syscalls (ptrace, mount, unshare, bpf)

[cluster2600]

Summary

The seccomp BPF filter in crates/openshell-sandbox/src/sandbox/linux/seccomp.rs (lines 37–65) only blocks SYS_socket for specific address families (AF_PACKET, AF_BLUETOOTH, AF_VSOCK, and optionally AF_INET/AF_INET6/AF_NETLINK). The default action is SeccompAction::Allow.

The following dangerous syscalls are not blocked:

• ptrace — attach to sibling processes, read memory, inject code
• mount / umount2 / pivot_root — overlay filesystems, escape Landlock
• unshare / clone (with namespace flags) — create new mount namespaces
• bpf — load BPF programs
• keyctl — kernel keyring manipulation
• kexec_load, init_module, finit_module — kernel module loading
• reboot, sethostname, setdomainname

Additionally, when NetworkMode::Allow is set (lines 16–19), the entire seccomp filter is skipped, including PR_SET_NO_NEW_PRIVS. This means setuid binaries could escalate privileges.

Impact

• Severity: High
• Combined with SYS_ADMIN capability (see related issue), a sandboxed process can call ptrace(PTRACE_ATTACH) on siblings, mount to overlay filesystems, or unshare(CLONE_NEWNS) to escape Landlock restrictions.

Proposed Fix

1. Switch to allowlist-based seccomp or add explicit blocks for high-risk syscalls
2. Always set PR_SET_NO_NEW_PRIVS and apply a baseline seccomp filter regardless of network mode
3. Block at minimum: ptrace, mount, umount2, pivot_root, chroot, unshare, clone3 (with namespace flag checks), keyctl, bpf, userfaultfd, perf_event_open

graph LR
    subgraph "Current seccomp"
        A[Default: ALLOW] --> B[Block AF_PACKET]
        A --> C[Block AF_BLUETOOTH]
        A --> D[Block AF_VSOCK]
        A --> E["Everything else: ✅ allowed"]
    end

    subgraph "Proposed seccomp"
        F[Default: ALLOW] --> G[Block dangerous sockets]
        F --> H["Block ptrace, mount, unshare, bpf, keyctl"]
        F --> I["Always set PR_SET_NO_NEW_PRIVS"]
    end

Loading

[johntmyers]

Security triage determination: No-go (not actionable as a core security bug).

The report identifies a real hardening opportunity, but it overstates current exploitability in the deployed path. In the managed flow, sandbox execution drops to the sandbox user before restrictions are applied, and proxy mode is the active runtime mode for policy-driven sandboxes. This is not showing a concrete break of a core trust boundary (gateway auth, gRPC channel isolation, or cross-tenant escape) as currently implemented.

This should be tracked as defense-in-depth seccomp hardening, not as a high-severity vulnerability ticket.