Skip to content

fix(policy): remove blanket /Volumes read grant from system_read_macos - #1769

Merged
SequeI merged 1 commit into
mainfrom
removeVolumes
Sep 2, 2026
Merged

SequeI merged 1 commit into
mainfrom
removeVolumes

Conversation

@SequeI

@SequeI SequeI commented Sep 2, 2026

Copy link
Copy Markdown
Member

Linked Issue

Closes #727
Ref #1482

Summary

The system_read_macos group granted read access to the entire /Volumes mount namespace (all external drives, disk images, and network shares), described only as paths "required for executables to function." No executable or system path resolution actually needs this — unlike /System/Volumes, which stays in the list because its required to match APFS firmlink-resolved paths (see docs/cli/internals/seatbelt.mdx).

This mirrors the fix already applied to the macOS runtime baseline in a9263ed, which removed an analogous overbroad /System/Volumes grant for the same reason: it could inadvertently expose user data. The system_read_macos policy group never got the same scrutiny.

Reported in discussion #1482, where an external drives contents were readable by every sandboxed process by default with no way to opt out short of a custom deny + --bypass-protection workaround.

Adds a regression test asserting /Volumes is absent from system_read_macos while /System/Volumes remains present.

Test Plan

Checklist

  • An issue exists and is linked above
  • All commits are signed-off, using DCO
  • All new code follows the project's coding standards (CLAUDE.md) and is covered by tests
  • Public-facing changes are paired with documentation updates
  • If this PR introduces a major feature, capability, or security-relevant change, a corresponding NEP has been opened or accepted and is linked

The system_read_macos group granted read access to the entire /Volumes
mount namespace (all external drives, disk images, and network shares),
described only as paths "required for executables to function." No
executable or system path resolution actually needs this — unlike
/System/Volumes, which stays in the list because its required to match
APFS firmlink-resolved paths (see docs/cli/internals/seatbelt.mdx).

This mirrors the fix already applied to the macOS runtime baseline in
a9263ed, which removed an analogous overbroad /System/Volumes grant
for the same reason: it could inadvertently expose user data. The
system_read_macos policy group never got the same scrutiny.

Reported in discussion #1482, where an external drives contents were
readable by every sandboxed process by default with no way to opt out
short of a custom deny + --bypass-protection workaround.

Adds a regression test asserting /Volumes is absent from
system_read_macos while /System/Volumes remains present.

Signed-off-by: Aleksy Siek <aleksy@nolabs.ai>
@github-actions github-actions Bot added bug Something isn't working nono-cli size/small labels Sep 2, 2026
@github-actions

github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

PR Review Summary

Size

Metric Value
Lines added +26
Lines removed -1
Total changed 27
Classification Small (< 50 lines)

Affected crates

  • crates/nono-cli — CLI changes. Verify argument parsing, flag documentation, and UX behaviour across supported platforms.

Blast radius — Moderate

This PR touches: source code,configuration / policy files


Updated automatically on each push to this PR.

@nogent-nolabs-ai nogent-nolabs-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nogent code review

No blocking issues; 0 findings.

Findings: none flagged in scope.

Automated code + security review. CI already covers clippy, rustfmt, tests, cargo-audit and commit-lint.

@SequeI
SequeI merged commit f3ce16f into main Sep 2, 2026
18 checks passed
levonk pushed a commit to levonk/nono that referenced this pull request Sep 4, 2026
nolabs-ai#1769)

The system_read_macos group granted read access to the entire /Volumes
mount namespace (all external drives, disk images, and network shares),
described only as paths "required for executables to function." No
executable or system path resolution actually needs this — unlike
/System/Volumes, which stays in the list because its required to match
APFS firmlink-resolved paths (see docs/cli/internals/seatbelt.mdx).

This mirrors the fix already applied to the macOS runtime baseline in
a9263ed, which removed an analogous overbroad /System/Volumes grant
for the same reason: it could inadvertently expose user data. The
system_read_macos policy group never got the same scrutiny.

Reported in discussion nolabs-ai#1482, where an external drives contents were
readable by every sandboxed process by default with no way to opt out
short of a custom deny + --bypass-protection workaround.

Adds a regression test asserting /Volumes is absent from
system_read_macos while /System/Volumes remains present.

Signed-off-by: Aleksy Siek <aleksy@nolabs.ai>
@SequeI
SequeI deleted the removeVolumes branch September 4, 2026 14:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working nono-cli size/small

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add_deny_access does not override group-level allows on macOS (Seatbelt)

2 participants