Repository navigation
[DGX Spark][Security] OpenClaw control-UI (dashboard) bearer token stored in sandbox-readable config (openclaw.json + .last-good) #8693
Description
Description
On an OpenClaw sandbox, the OpenClaw control-UI ("dashboard") bearer token is persisted in sandbox-readable configuration. It appears in both /sandbox/.openclaw/openclaw.json (mode 660, owner sandbox:sandbox — readable by the sandbox user) and /sandbox/.openclaw/openclaw.json.last-good (mode 600, owner sandbox:sandbox). Three independent scans reproduced it; the raw value was never copied into evidence.
Technical context (so severity can be calibrated): the token authenticates the OpenClaw control UI, which is bound to loopback only — gateway.mode=local, port 18789, trustedProxies=[127.0.0.1, ::1], controlUi.allowedOrigins=[http://127.0.0.1:18789], with allowInsecureAuth and dangerouslyDisableDeviceAuth intentionally enabled for the local dashboard. It is the sandbox's own OpenClaw gateway token (OpenClaw runs inside the sandbox and serves that control UI), not a host/OpenShell credential; the sandbox↔host boundary (OpenShell egress policy + Landlock) is enforced separately. Whether the in-sandbox agent holding this token is an escalation depends on the NemoClaw threat model, which was not established here.
Hardening rationale: comparable secure-sandbox products (e.g. Docker Sandboxes) keep control credentials in a host-side/injection-only store and never persist them inside the sandbox or its backups. A bearer credential sitting in sandbox-readable config and in a .last-good backup is weaker than that benchmark and is flagged as a release-blocker pending threat-model review.
Platform scope: Reproduced on DGX Spark (NemoClaw v0.0.103, LKG). Not separately tested on other platforms; the config layout is not Spark-specific.
Regression: Unknown — earlier versions not tested.
Environment
Device: DGX Spark (GB10)
OS: Ubuntu 24.04.4 LTS (DGX OS 7.5.0)
Architecture: aarch64
Node.js: v22.23.1
npm: 10.9.8
Docker: 29.2.1
OpenShell CLI: 0.0.85
NemoClaw: v0.0.103
OpenClaw: 2026.7.1
Steps to Reproduce
- Onboard an OpenClaw sandbox (any inference provider; Local Ollama used here).
- Inspect the sandbox-visible config from inside the sandbox:
nemoclaw {sandbox} exec -- bash -lc 'stat -c "%a %U:%G" /sandbox/.openclaw/openclaw.json /sandbox/.openclaw/openclaw.json.last-good' # then check whether gateway.auth.token is present in /sandbox/.openclaw/openclaw.json
Expected Result
The control-UI bearer credential should not be readable by the sandbox user or stored in sandbox persistent config/backups. It should be held host-side and injected through a narrow authenticated channel at runtime, with a self-check that reports/rotates any credential found across the boundary.
Actual Result
The dashboard bearer token is present in sandbox-readable config:
/sandbox/.openclaw/openclaw.json perms=660 sandbox:sandbox gateway.auth.token present = True
/sandbox/.openclaw/openclaw.json.last-good perms=600 sandbox:sandbox
Control-UI is loopback-scoped:
gateway.mode=local port=18789 trustedProxies=[127.0.0.1, ::1]
controlUi.allowedOrigins=[http://127.0.0.1:18789]
controlUi.allowInsecureAuth=True controlUi.dangerouslyDisableDeviceAuth=True
Controls: the injected canary and the Ollama proxy token were absent; the dashboard token was absent from logs, the debug archive, snapshots, and host-state search.
Logs
Not captured (raw token value intentionally not recorded). Presence confirmed by boolean check and stat only.
Activity
hulynn commentedon Aug 10, 2026
@laitingsheng Also observed in the process environment (not only the config file). On a separate DGX Spark run, both credentials were live in the main sandbox process environment and inherited by the OpenClaw process plus child
shell/teeprocesses:NEMOCLAW_OLLAMA_PROXY_TOKEN(71 bytes) — the host Ollama auth-proxy tokenOPENCLAW_GATEWAY_TOKEN(43 bytes) — the gateway/control-UI token (same credential as thegateway.auth.tokenin this issue)Exact-value searches of files, logs, the debug archive, UI artifacts, and current artifacts found no copies, so credential absence cannot be claimed. Same root cause as this issue (the sandbox holds its own raw scoped tokens); the process-environment surface is slightly broader than the config file, since any subprocess the agent spawns inherits the tokens in its
env.fix(security): strip gateway token from descendants (#8872)
apurvvkumaria commentedon Aug 12, 2026
Maintainer status:
OPENCLAW_GATEWAY_TOKENfrom the initial gateway process, automatic respawns, and their descendants. It does not remove the token fromopenclaw.json,openclaw.json.last-good, or other same-UID-readable state. Its post-merge managed OpenShell activation check also exposed a gateway startup regression.--token. I requested changes because the managed sandbox agent can read the gateway command line through/proc/<pid>/cmdline; that approach moves the credential to another same-UID-readable process surface./proc/<pid>/environand/proc/<pid>/cmdline, scan the active config and recovery copies, and pass exact managed-image activation. Repository security review and documentation review remain required.I am keeping this issue open. The partial environment fix and the current PR do not satisfy the reported config and backup exposure.
fix(sandbox): preserve gateway auth at launch (#8921)
apurvvkumaria commentedon Aug 13, 2026
Corrected maintainer status after tracing the current OpenShell and OpenClaw contracts:
There are two complete remediation paths:
The static bearer cannot be made secret from a same-identity process merely by moving it among config, argv, environment, or backup files. No additional local token-shuffling PR should claim to close this issue.
Recommendation: choose path 1 if host-side OpenClaw gateway execution is acceptable to the NemoClaw product threat model; otherwise record path 2 as the precise OpenShell dependency. In either case, closure needs live acceptance proving the sandbox user cannot obtain or use the dashboard credential, including config/recovery files, process argv/environment, automatic restart, and direct-bypass attempts.
apurvvkumaria commentedon Aug 13, 2026
Maintainer update: this issue requires an explicit OpenShell/OpenClaw ingress-authentication design decision before further implementation.
Hard architecture constraint: the OpenClaw gateway must remain inside the existing OpenShell sandbox and in the same trust boundary as the agent/tool workload. Moving the gateway to the host or introducing a separately trusted gateway identity is not an acceptable remediation.
The remaining defect is not a token-placement bug. A static dashboard bearer stored anywhere readable by this shared trust boundary—config or recovery files, argv, environment, or another process-readable surface—can be recovered and used by the sandbox agent. Moving the bearer between those surfaces cannot satisfy this issue.
The required direction is to eliminate the sandbox-held raw dashboard bearer and broker inbound dashboard authentication through OpenShell:
The existing OpenShell provider contract does not directly solve this because it brokers credentials on sandbox outbound requests. The current
openshell forwardpath is a raw transport and does not provide cryptographically authenticated inbound proxy identity. OpenClaw has trusted-proxy authentication, but source/header trust alone is insufficient when a same-sandbox process can connect directly and forge proxy headers.OpenShell's sandbox-ingress design work may provide the relay and caller-authentication foundation, but OpenShell and OpenClaw maintainers need to agree on the authenticated relay/proof contract and direct-bypass prevention before another NemoClaw implementation PR is opened. No host-gateway or separate-trust-boundary redesign should be pursued.
PRs #8872 and #8921 remain useful defense-in-depth: they remove the bearer from gateway argv/environment and harden launch/log behavior. They do not close the config/recovery-file exposure reported here.
Acceptance must prove that the sandbox user cannot obtain or use dashboard authorization through config/recovery files, argv, environment, process inspection, forged proxy headers, replay, or direct loopback/forwarding bypass; and that initial launch, automatic restart, trusted dashboard access, and exact managed E2E all work.
prekshivyas commentedon Aug 24, 2026
Maintainer decision: The sandbox-readable OpenClaw gateway token is an accepted known risk in the current OpenClaw/NemoClaw model. PRs #8872 and #8921 remain useful defense-in-depth, but we will not pursue a new OpenShell/OpenClaw authentication design at this time. Closing as not planned; this can be reopened if the product threat model or architecture decision changes.