Conversation
The macOS enforcement probe now reads a file in the real home directory outside the project, and a file in nvx's home outside its runtimes, from inside the sandbox. Each read must be refused by the OS with EPERM or EACCES. A fourth phase repeats the nvx home check with an NVX_HOME under /var/folders, outside the home. The controls sit under the home too, so a profile that denied all of it fails them: a read of the project, of the runtime the process runs, and of a directory the policy names in allow_read_exec. The project, NVX_HOME and that directory move under $HOME for this reason. The probe and the macOS smoke install an nvx-managed runtime first, as the Linux probe does. The runner's own node is under /Users/runner/hostedtoolcache, inside the home. The launch-escape probe names that node's install directory in allow_read_exec instead. The Seatbelt profile allows every read outside the credential stores, so this commit fails on macOS. The next one narrows the profile.
The Seatbelt profile allowed every read and denied only the credential stores. A contained process could read every other file in the home directory, other projects included, and nvx's own home: grants, policy and tool_home credentials. On the macOS runner the probe from the previous commit read a file in the home outside the project, a file in an NVX_HOME under the home, and a file in an NVX_HOME under /var/folders. Windows and Linux already deny reads of the home. After the blanket read allow the profile now denies reads of the real home and of nvx's home, named as given and with links resolved. Metadata stays readable. It then reopens what Linux grants: the project, the guest home, every allow_read_exec root, and nvx's versions, bin and current. The credential-store denies stay last, so a project or an allow_read_exec root that holds a store does not expose it. The runtime trees are now one list shared with the Landlock rules. A runtime under the home outside nvx, such as one installed by nvm, needs its directory in allow_read_exec, as it already does on Linux.
The enforcement matrix, SECURITY.md, README and PRODUCT.md said macOS allowed every read outside the credential stores. They now say reads under the home directory and nvx's home are denied apart from what a run needs, and that reads elsewhere on the disk stay allowed. The matrix records the two macOS runs: 37399750782 read all three files before the profile change, 37400274341 refused them with every control passing.
…eads # Conflicts: # CHANGELOG.md # docs/enforcement-matrix.md
This branch has not been deployed
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.
On macOS a contained process could read every file in the home directory outside the credential stores, other projects included, and nvx's own home: grants, policy and
tool_homecredentials. Windows and Linux already deny reads of the home directory. This makes macOS match.Change
After the blanket
(allow file-read*)the Seatbelt profile now:file-read*on the real home and on nvx's home (NVX_HOMEmay be outside the home), each named as given and with links resolvedfile-read-metadataon both again, so tools can still stat ancestors of the projectfile-read*on what Linux grants: the project, the guest home, everyallow_read_execroot, andNVX_HOME/versions,binandcurrentallow_read_execroot that holds a store does not expose itThe runtime trees are one list shared with the Landlock rules. Both launch paths pass
NvxHomeandReadExecRootsto the profile builder.A runtime under the home outside nvx (nvm, the hosted runner's toolcache) now needs its directory in
allow_read_execto run contained, as it already does on Linux.Evidence
READ_OUTSIDE=ALLOWED,NVX_HOME_READ=ALLOWED, and the phase 4 read of a file in anNVX_HOMEunder/var/foldersexiting 0. Every control passed,CONNECT=200included. The run as a whole shows cancelled because the next push superseded its Windows job.READ_OUTSIDE=DENIED,NVX_HOME_READ=DENIED, phase 4 exit 3. The controlsREAD_INSIDE,READ_RUNTIME,READ_EXEC_ROOT, phase 3's project and runtime reads andCONNECT=200all passed. The macOS smoke's containednpm installand nested-runtime check passed. The launch-escape probe reported all three vectors DENIED, with its node running from anallow_read_execroot.grants,tool_home,policy.jsonor another session's guest home. It fails against the old builder.The probe and the smoke now install an nvx-managed runtime first, because the runner's node lives under the home. The enforcement probe's project,
NVX_HOMEandallow_read_execfixture sit under$HOME, so the controls exercise the reopened paths.