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 like cap_sys_admin, cap_net_raw, cap_net_bind_service, cap_sys_ptrace, cap_dac_override, cap_fowner, cap_setuid, and cap_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]
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
capsh --print.Current:shows no capabilities set (effective set is empty).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.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
2-3. capsh output shows restricted capability set
If any of the above capabilities are present, the test FAILs.
Bug Details
[NVB#6159223]