Policy file path from environment (path traversal)

[pimlock]

Summary

When loading the dev sandbox policy, the CLI checks the NAVIGATOR_SANDBOX_POLICY environment variable. If set, it is used as a file path and the file is read with std::fs::read_to_string(path). The path is not canonicalized or validated; it is not restricted to a safe directory. If an attacker can set this environment variable, they can read arbitrary files the process can access. Parse failures can leak file content in the error message.

Source Code

• In crates/navigator-cli/src/run.rs, load_dev_sandbox_policy (lines 1231-1245) does std::env::var("NAVIGATOR_SANDBOX_POLICY"). On success it sets path = Path::new(&policy_path) and calls std::fs::read_to_string(path) with no canonicalization or check that the path stays within a safe tree.

---

Originally by @drew on 2026-02-19T09:01:55.805-08:00

[johntmyers]

🔒 security-review-agent

Security Review

Determination: Not actionable

Rationale

The claimed vulnerability is that NEMOCLAW_SANDBOX_POLICY (the issue incorrectly names it NAVIGATOR_SANDBOX_POLICY) allows reading arbitrary files via path traversal. While the code at crates/navigator-policy/src/lib.rs:360-375 does indeed read a file path from this environment variable without canonicalization or directory restriction, this is not a security concern for the following reasons:

1. CLI-only surface: The NEMOCLAW_SANDBOX_POLICY env var is only consumed by the navigator-cli binary — a local command-line tool. It is not read by the server (navigator-server) or the sandbox supervisor. The env var controls which policy file the CLI loads before sending it to the server via gRPC.

2. No privilege boundary crossed: An attacker who can set environment variables for the CLI process already has local code execution as that user. They can already read any file the process can access (cat /etc/passwd, etc.) without exploiting this env var. There is no privilege escalation.

3. Design intent: Both the --policy CLI flag and the NEMOCLAW_SANDBOX_POLICY env var are explicitly designed to accept arbitrary file paths as a user convenience feature. Restricting them to a "safe directory" would break the intended UX with no security benefit.

4. Error message leakage is local-only: Even if serde_yaml parse errors include input snippets, those errors are displayed on the terminal of the user who invoked the CLI — the same user who could read the file directly.

The threat model described in the issue (attacker sets env var → reads arbitrary files) requires the attacker to already have the access that the "vulnerability" would supposedly grant. This is a non-issue.

References

• crates/navigator-policy/src/lib.rs:360-375 — load_sandbox_policy function
• crates/navigator-cli/src/run.rs:1484-1486 — CLI wrapper that delegates to the policy crate
• No server-side or sandbox-side consumption of this env var