Repository navigation
fix(policy): remove blanket /Volumes read grant from system_read_macos - #1769
Merged
Merged
Conversation
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>
Contributor
PR Review SummarySize
Affected crates
Blast radius — ModerateThis PR touches: source code,configuration / policy files Updated automatically on each push to this PR. |
connrg
approved these changes
Sep 2, 2026
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>
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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