Repository navigation
[Nemoclaw] [All Platforms] Sandbox allows dangerous capabilities in bounding set despite empty effective set #3280
Description
Description
When the sandbox process is started, it drops all effective capabilities but leaves a broad set of dangerous capabilities in its capability bounding set, allowing them to be regained under some conditions. The sandbox test currently only checks the effective capability set, so these high‑risk capabilities are not detected and the environment is incorrectly treated as secure.
Working State
With only safe capabilities available, the sandbox should have an empty effective capability set and a tightly restricted bounding set that excludes known dangerous capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, CAP_NET_BIND_SERVICE, CAP_SYS_PTRACE, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_SETUID, and CAP_SETGID.
Steps to reproduce
- Enter the sandbox shell (for example, via your usual “open sandbox” or equivalent command).
-
Inside the sandbox, run
capsh --print. -
Observe that
Current:shows no capabilities set (effective set is empty). -
Observe that the
Bounding set =line still includes dangerous capabilities likecap_sys_admin,cap_net_raw,cap_net_bind_service,cap_sys_ptrace,cap_dac_override,cap_fowner,cap_setuid, andcap_setgid. - Run your sandbox capability test and note that it only validates the current effective capability set and does not fail on the presence of these capabilities in the bounding set.
Actual Result
The sandbox process runs with an empty effective capability set, but the capability bounding set still contains multiple dangerous capabilities (including CAP_SYS_ADMIN, CAP_NET_RAW, CAP_NET_BIND_SERVICE, CAP_SYS_PTRACE, CAP_DAC_OVERRIDE, CAP_FOWNER, CAP_SETUID, and CAP_SETGID). The test logic reports this environment as passing, even though these capabilities remain available in the bounding set and could potentially be regained, leaving a larger attack surface than intended.
Expected Result
- Sandbox entered
2-3. capsh output shows restricted capability set - The following dangerous capabilities MUST NOT appear in the capability set:
- CAP_SYS_ADMIN
- CAP_NET_RAW
- CAP_NET_BIND_SERVICE
- CAP_SYS_PTRACE
- CAP_DAC_OVERRIDE
- CAP_FOWNER
- CAP_SETUID
- CAP_SETGID
If any of the above capabilities are present, the test FAILs.
Bug Details
| Field | Value |
|---|---|
| Priority | Unprioritized |
| Action | Dev - Open - To fix |
| Disposition | Open issue |
| Module | Machine Learning - NemoClaw |
| Keyword | NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL, NemoClaw_Sandbox |
[NVB#6159223]
Activity
test(sandbox): inventory dangerous-cap set in bounding-set assertion (N…
fix(sandbox): replace gosu with setpriv to drop all bounding-set caps (…
test(sandbox): require all 8 issue-3280 caps absent after step-down (N…
fix(sandbox): replace gosu with setpriv to drop all bounding-set caps (…
test(sandbox): require all 8 issue-3280 caps absent after step-down (N…
30 remaining items
fix(platform): clear advisor PRA-3, PRA-5, PRA-6 + add PRA-4 test
cjagwani commentedon Jun 26, 2026
Upstream movement: OpenShell maintainer Adrien Langou opened NVIDIA/OpenShell#2001 implementing the proposal we agreed on. Drops the capability bounding set in the supervisor's child-process privilege-drop path so workloads and
openshell connectshells can't regain container-granted caps after exec. Verified output from a shell in the PR showsCapBnd: 0000000000000000(was the broad00000004a82c35fbbefore). Waiting on upstream review + merge, then we'll test the build on the NemoClaw side and close this out.cjagwani commentedon Jun 29, 2026
Upstream is in. NVIDIA/OpenShell#2001 (Adrien Langou) merged earlier today and lands the bounding-set drop in the common sandbox child privilege-drop path. After the fix,
CapBnd: 0000000000000000on a connect shell, down from the old broad00000004a82c35fb.Reading through #2001, The drop happens inside
drop_privileges(), which is the single path every sandbox child takes (both workloads andopenshell connectshells), and there's a newpre_exec_always_calls_drop_privilegestest enforcing that nothing can bypass it. The drop sits aftersetgid/initgroupsand beforesetuidso the supervisor bootstrap is unaffected, and there's a graceful fallback whenCAP_SETPCAPisn't available.To fully close on the NemoClaw side we need to wait for an OpenShell release that includes #2001, bump NemoClaw's OpenShell pin, and have NV QA re-verify on Colossus (NVB6159223).
cjagwani commentedon Aug 20, 2026
VDR re-verification update: the upstream dependency blocker is resolved and the filed connect-shell acceptance criterion now passes on the current pinned runtime on this host.
Release lineage:
afc06dd2a4ae9b269832657cdd8016e52bde3bbfand introduced the common child-process bounding-set drop.bed2590be34617f75185499e46e584a3a6c39f5e) pins OpenShell exactly to v0.0.106 innemoclaw-blueprint/blueprint.yaml.Fresh real-runtime proof:
desktop-linux, aarch64).openshell 0.0.106.sy-v4-final17.openshell sandbox connect sy-v4-final17path, notdocker exec.This proves all eight capabilities named in #3280 are absent from the connect-shell bounding set on the current macOS/Docker Desktop path. No additional NemoClaw source change is indicated.
@hulynn / NV QA: please rerun the filed check on the original Colossus Ubuntu 24.04 environment with NemoClaw v0.0.112 (OpenShell v0.0.106). Enter the sandbox normally, then inspect the current connect child:
Expected:
CapEffandCapBndare both all zero. If Colossus matches, this issue can close as verified; if it does not, please attach the OpenShell version, capability fields, and gateway/sandbox logs so we can isolate a host-specific runtime regression.prekshivyas commentedon Aug 28, 2026
Implementation is complete and the bounding-set fix is included in the current pinned OpenShell runtime. Closing this GitHub issue as completed. NVBug 6159223 has been moved to
QA - Open - Verify to closewith dispositionBug - Fixedfor final NV QA verification on the original Colossus Ubuntu 24.04 environment.