Repository navigation
feat(sandbox): support --cap-drop / capability scoping on sandbox create #1452
Description
Summary
Requesting support for --cap-drop (or equivalent capability-set scoping) on openshell sandbox create so consumers can reduce the OCI bounding set of sandbox containers at creation time.
Context
NemoClaw isolates agents inside OpenShell sandboxes and drops dangerous capabilities from the agent process tree via capsh + setpriv in its entrypoint (NemoClaw PRs #3328 + #3329). That hardens the agent code path but does NOT reduce the container's OCI bounding set itself.
When users nemoclaw sandbox connect, the runtime spawns a shell outside the agent process tree. That shell sees the container's OCI bounding set, which still contains:
CAP_SYS_ADMINCAP_NET_RAWCAP_NET_BIND_SERVICECAP_SYS_PTRACECAP_DAC_OVERRIDECAP_FOWNERCAP_SETUIDCAP_SETGID
Verified from inside a v0.0.43 sandbox with capsh --print: NVIDIA/NemoClaw#3280
Why NemoClaw can't fix this alone
openshell sandbox create doesn't accept --cap-drop or any capability-scoping flag, and the OpenShell policy schema has no capability section. The OCI bounding set is set by OpenShell at container-create time, so NemoClaw has no way to reduce it.
Asks
One of:
--cap-drop/--cap-addflags onopenshell sandbox create— matches Docker semantics, smaller surface changecapabilities:section in the OpenShell policy schema with allow/drop lists translated to the OCI bounding set at container-create time — more declarative, tracks better with existing policy-driven model
Either works for NemoClaw's use case.
Consumer / blocker
NemoClaw issue #3280 (priority: high, NV QA) is blocked on this. Scope is shell-scope cap tightening for sandbox connect shells.
Activity
fix(sandbox): add opt-in fail-closed cap-drop enforcement (#4707)
fix(sandbox): cap sandbox open file descriptors (nofile) at entrypoint
fix(sandbox): cap sandbox open file descriptors (nofile) at entrypoint (
cjagwani commentedon Jun 11, 2026
Hey OpenShell team, pinging this for visibility. NemoClaw issue #3280 is partially blocked on this.
NemoClaw can drop dangerous bounding-set caps from the agent process tree via
setpriv/capsh --dropwhen CAP_SETPCAP is available. On hosts where the container's create-time bounding set lacks CAP_SETPCAP (Colossus Ubuntu 24.04, Docker Desktop on Windows, WSL), no in-container drop is possible. That leaves dangerous caps visible to anything that exec's into the sandbox, which our QA team flagged as a security regression.The only fix is
--cap-drop(or acapabilities:policy section) atopenshell sandbox createtime, which is what this issue tracks.Is this on the roadmap? Happy to open a PR if you can sketch the desired shape (CLI flag vs policy YAML, defaults). I have the implementation bandwidth and the QA repro to validate against.
johntmyers commentedon Jun 12, 2026
@alangou Could you take a look at this? Sounds like we have some privilege-regain risk we need to classify. Not sure if a user-facing flag is the right approach here, mostly because I don't know if there is a use case where we should allow these caps to be available for exec sessions.