fix(supervisor): tolerate non-empty bounding set when CAP_SETPCAP is unavailable

[waynesun09]

Summary

When running under rootless Podman (or any container runtime that drops CAP_SETPCAP), cap_drop_bound() returns EPERM for every capability still in the bounding set. Since v0.0.73 this is fatal — the supervisor crashes on sandbox startup, breaking all rootless Podman deployments.

This PR adds a third match arm to validate_capability_bounding_set_clear() that tolerates EPERM when the bounding set is non-empty, logging a warning instead of returning an error. The sandbox still relies on seccomp and Landlock for confinement in this case.

Related Issue

Fixes #2069

Changes

• crates/openshell-supervisor-process/src/process.rs:
  • Add EPERM + non-empty bounding set tolerance branch between the existing EPERM + empty (success) and catch-all (error) arms
  • Import warn from tracing
  • Update capability_bounding_set_clear_tolerates_nonempty_eperm test to assert is_ok() instead of is_err()
  • Simplify drop_privileges_succeeds_for_current_group test — remove conditional cfg(target_os) branching
• .github/workflows/branch-checks.yml: Add rootless-caps CI job that runs supervisor capability tests as a non-root user without CAP_SETPCAP on ubuntu-24.04

Local Build & Test

Built and tested the fix locally before pushing:

1. Cross-compiled supervisor as a static aarch64-unknown-linux-musl binary inside a rust:1.95-bookworm Podman container (macOS host cannot build Linux-only deps: capctl, landlock, seccompiler)
2. Packaged into local OCI image localhost/openshell-supervisor:fix-2069 via Dockerfile.supervisor
3. Configured gateway to use the local supervisor image (supervisor_image = "localhost/openshell-supervisor:fix-2069" in gateway.toml)
4. Tested sandbox creation — sandbox reached Phase: Ready with the expected warning:

   CAP_SETPCAP is unavailable and the child capability bounding set is non-empty;
   the child process relies on seccomp and Landlock for confinement
   

5. Ran a fullsend agent code review pipeline against the fixed supervisor — sandbox created (7.4s), bootstrapped, agent code copied into sandbox — all stages succeeded

Testing

• cargo test -p openshell-supervisor-process --lib -- capability_bounding drop_privileges passes
• Local supervisor build + sandbox creation test (rootless Podman on macOS)
• Fullsend agent pipeline run with fixed supervisor image — sandbox lifecycle (create, bootstrap, code copy) verified
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

All contributors have signed the DCO ✍️ ✅
_{Posted by the DCO Assistant Lite bot.}

[waynesun09]

I have read the DCO document and I hereby sign the DCO.

[waynesun09]

recheck

[maxamillion]

Few points of note:

• Security boundary behavior changed but architecture docs were not updated.
  architecture/sandbox.md still says child capability bounding-set clearing is fail-closed and that EPERM is tolerated only when the set is already empty. This PR intentionally changes that invariant. The architecture doc should be updated in the same PR to describe the degraded rootless mode and its reliance on seccomp/Landlock.

• The degraded path relies on Landlock, but Landlock may be best-effort.
  The warning says the child relies on “seccomp and Landlock,” but elsewhere Landlock can run in best-effort mode and continue unavailable or failed. If the bounding set remains non-empty and Landlock is unavailable/best-effort, the actual confinement story is weaker than the warning implies. Consider tightening the message or adding an explicit check/comment explaining acceptable residual risk.

• Consider emitting this as an OCSF security/config event, not only tracing::warn!.
  Per project logging guidance, degraded sandbox controls and unavailable confinement primitives are operator-visible security posture events. This warning represents a confinement degradation and may warrant a structured OCSF finding or config-state event so it appears in sandbox security telemetry.

• Commit metadata includes Assisted-by: Claude.
  Project instructions say commits must not mention Claude or AI agents. The commit bodies in this PR include Assisted-by: Claude; those should be removed before merge.

[TaylorMutch]

/ok to test 1dc253d

[elezar]

@alangou could this have been introduced in #2001? Do you mind having a look?

[alangou]

/ok to test 3f95d51

[alangou]

The new OCSF degraded-mode alert may not fire.

The parent-side probe returns early if CAP_SETPCAP is present in the effective set, but the commit message says Podman can grant CAP_SETPCAP while AppArmor still makes bounding::clear() fail with EPERM. Then we skip the parent DetectionFinding, and only hit the warn! inside pre_exec, which is exactly the context this patch says cannot reliably emit structured logs.

Could we make the readiness probe test the actual bounding-set clear behavior ?