feat(sandbox): add Windows deny-read parity

[viyatb-oai]

Summary

Adds Windows subprocess enforcement for split filesystem access = none read restrictions, now that the exact/glob deny-read policy stack has landed on main.

This PR keeps the scope to Windows parity:

• Resolves Windows deny-read filesystem policy entries into concrete ACL targets.
• Preserves exact missing paths so they can be materialized and denied before the sandboxed process starts.
• Snapshot-expands existing glob matches into ACL targets for Windows subprocess enforcement.
• Plans both lexical and canonical targets for existing paths so reparse-point aliases do not bypass the deny.
• Threads deny-read overrides through both Windows sandbox backends:
  • restricted-token backend capability SID ACLs
  • elevated/logon-user backend sandbox group ACL setup
• Records persistent deny-read ACLs separately for restricted-token and elevated principals so stale cleanup does not cross backend ownership.
• Adds a Windows-only integration test that exercises exact and glob deny-read behavior through shell execution.

Landed Prerequisites

These base stack PRs are already on main:

1. feat(permissions): add glob deny-read policy support #15979 feat(permissions): add glob deny-read policy support
2. feat(sandbox): add glob deny-read platform enforcement #18096 feat(sandbox): add glob deny-read platform enforcement
3. feat(config): support managed deny-read requirements #17740 feat(config): support managed deny-read requirements

This PR now targets main directly and contains only the Windows deny-read parity layer.

Implementation Notes

• Exact deny-read paths are kept even when missing, then materialized as directories before applying the deny ACE. This is fail-closed: a sandboxed command cannot create that denied path and read it during the same run.
• Existing deny-read paths are planned as both the configured lexical path and the canonical target. This covers path aliases caused by existing reparse points while still preserving the user-configured path.
• Glob deny-read entries are expanded to existing matches before process launch. Windows ACLs receive concrete paths only.
• Deny-read ACEs are applied after broad read grants so explicit deny entries take precedence.
• Stale persistent deny-read ACL cleanup is keyed by backend principal kind to avoid revoking ACLs owned by the other Windows backend.

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/windows-sandbox-rs/src/lib.rs

Lines 420 to 423 in 954e7c2

	for path in additional_deny_write_paths {
	if path.exists() {
	deny.insert(path.clone());
	}

Apply deny-write ACLs to missing None carveouts

The restricted-token path only adds additional_deny_write_paths when the path already exists. New deny-read logic later materializes missing deny paths (apply_deny_read_acls), so a FileSystemAccessMode::None path that starts missing gets read-denied but not write-denied. A sandboxed process can still create/write descendants under that directory, violating None semantics.

---

codex/codex-rs/windows-sandbox-rs/src/lib.rs

Lines 420 to 423 in 954e7c2

	for path in additional_deny_write_paths {
	if path.exists() {
	deny.insert(path.clone());
	}

Apply deny-write ACLs to missing None carveouts

The restricted-token path only adds additional_deny_write_paths when the path already exists. New deny-read logic then materializes missing deny paths (apply_deny_read_acls), so a missing FileSystemAccessMode::None path becomes read-denied but not write-denied. A sandboxed command can still create/write under that directory, violating None semantics.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep lexical deny-read paths in elevated payloads

build_payload_deny_read_paths canonicalizes every existing deny-read path before sending it to the helper. This strips the lexical path variant that plan_deny_read_acl_paths is designed to preserve (lexical + canonical) for reparse-point alias coverage, so elevated setup no longer matches the stated alias-hardening intent.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Apply current deny-read payload even when helper is busy

When the read-ACL helper mutex exists, setup logs and skips spawning a helper, but deny-read ACL updates are now performed by that helper path. If policy changes while another helper run is active, the new deny-read payload is dropped for this command, so execution can proceed with stale deny rules.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Avoid cross-pattern scan dedupe by canonical directory only

Global seen_scan_dirs keys scans by canonical path. If two unreadable globs use different lexical roots that resolve to the same target (junction/symlink aliases), the second root is skipped entirely. Alias-specific matches from later patterns are then never added to deny ACL targets.

Useful? React with 👍 / 👎.