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

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).