Description

Description

The NemoClaw sandbox startup script hardens nproc (process count) via ulimit but does NOT cap nofile (open file descriptors). As a result, the sandbox inherits whatever default the Docker daemon hands out — typically 1048576 (1M) — even when its parent runtime / host shell has a much lower limit. This breaks the security invariant that the sandbox should not be more privileged than the process that launched it.

Surface area: any sandbox starting via the standard NemoClaw onboard flow on hosts whose host shell ulimit -n is below the Docker daemon default. Confirmed on dgxspark; identical pattern expected wherever Docker daemon ships its default-ulimits=1048576 (most modern Linux distros).

OS:            Linux (Ubuntu 22.04 / Ubuntu 24.04 / DGX Spark / DGX Station)
Architecture:  x86_64, aarch64
Node.js:       v22.22.3
Docker:        Docker Engine 29.4.1 (daemon default nofile = 1048576)
OpenShell CLI: openshell 0.0.44
NemoClaw:      v0.0.53
OpenClaw:      2026.5.22

1. On a Linux host where the launching shell has a finite nofile soft limit (e.g. gitlab-runner shell on dgxspark: 500000).
2. `nemoclaw onboard --non-interactive --yes-i-accept-third-party-software`.
3. Inside the sandbox: `ulimit -n`.
4. Compare against the host shell's `ulimit -n` on the host.

Sandbox nofile soft limit is capped at or below the launching process's nofile. The product should harden nofile the same way it already hardens nproc.

Compare with scripts/nemoclaw-start.sh:95-103 which already caps nproc:

    # Harden: limit process count to prevent fork bombs (ref: #809)
    if ! ulimit -Su 512 2>/dev/null; then
      echo "[SECURITY] Could not set soft nproc limit (...)" >&2
    fi
    if ! ulimit -Hu 512 2>/dev/null; then
      echo "[SECURITY] Could not set hard nproc limit (...)" >&2
    fi

Inside the sandbox:

    sandbox$ ulimit -n
    1048576

Host launching shell:

    host$ ulimit -n
    500000

Bug Details

[NVB#6241295]