sec(sandbox): reduce SYS_ADMIN and SYS_PTRACE capabilities on sandbox pods

[cluster2600]

Summary

Sandbox pods are granted SYS_ADMIN, NET_ADMIN, SYS_PTRACE, and SYSLOG capabilities at crates/openshell-server/src/sandbox/mod.rs (lines 918–928), whilst running as runAsUser: 0 (line 742).

SYS_ADMIN is the most permissive Linux capability — it enables mount, umount, pivot_root, clone with namespace flags, BPF loading, and more. Combined with running as root, this is a significant container escape vector.

SYS_PTRACE allows attaching to any process in the same PID namespace, reading their memory, and injecting code.

Impact

• Severity: High
• A compromised sandbox supervisor process has root + SYS_ADMIN inside the container, enabling kernel-level operations that could lead to container escape.

Proposed Fix

1. Move network namespace setup to a short-lived init container or privileged sidecar with minimal scope
2. Drop capabilities after setup is complete (the supervisor only needs them during initialisation)
3. Add securityContext.allowPrivilegeEscalation: false to the sandbox pod spec
4. Add a pod-level seccomp profile
5. Investigate whether user namespaces could map root inside the container to an unprivileged host user

The gateway pod already demonstrates good practice: runAsNonRoot: true, runAsUser: 1000, allowPrivilegeEscalation: false, drops ALL capabilities (deploy/helm/openshell/values.yaml:28-34).

[johntmyers]

Security triage determination: No-go (design hardening, not a confirmed vulnerability).

The capabilities called out are currently part of the supervisor design to set up network isolation, proxy enforcement, and diagnostics. Untrusted workload processes are run as the sandbox user after privilege drop, so this issue does not currently demonstrate a direct break in the core control-plane trust boundary.

Reducing capabilities is a valid future hardening direction, but this report does not provide a concrete exploit path against core technology in current architecture.