Repository navigation
ZERO_DAEMON_REMOTE_TOKEN_FILE leaks the daemon bearer token into sandboxed commands #677
Description
Summary
PR #660 scrubs ZERO_DAEMON_REMOTE_TOKEN, but leaves ZERO_DAEMON_REMOTE_TOKEN_FILE in the inherited sandbox environment. The read-all sandbox posture lets the command read the referenced file.
Relevant code
internal/sandbox/runner.go:scrubSensitiveEnvincludesZERO_DAEMON_REMOTE_TOKENbut notZERO_DAEMON_REMOTE_TOKEN_FILE.internal/daemon/remote/auth.go:TokenFromEnvreads the bearer token from that path.
Observed at commit 6fc1220.
Reproduction
- Put a daemon bearer token in a file outside the workspace.
- Set
ZERO_DAEMON_REMOTE_TOKEN_FILEto its absolute path. - Launch a sandboxed command through Zero.
- The command can read the pointer and token file.
Suggested fix
Remove the pointer from the sandbox environment and add its resolved target to DenyRead, analogous to GOOGLE_APPLICATION_CREDENTIALS. Test both env scrubbing and filesystem denial.
Activity
Vasanthdev2004 commentedon Jul 28, 2026
Confirmed on current
main, and fixed in #818.scrubSensitiveEnv(internal/sandbox/runner.go:1008) listsZERO_DAEMON_REMOTE_TOKENand nothing matchesZERO_DAEMON_REMOTE_TOKEN_FILE, whileTokenFromEnvaccepts either form. So the pointer survived into the sandboxed environment and the read-all posture did the rest.The fix is the one line plus a test. I deliberately did not also add the target to the credential deny-read list: the path comes from that variable alone and there is no default location to guess at, so scrubbing it closes the leak outright, and touching the deny-read builder would collide with #816 for no extra protection.
fix(sandbox): scrub the daemon token file pointer (#677) (#818)
Merge upstream/main into credential deny-read hardening, with review …