[2.23.1] nix sandbox broken on darwin #11002

utkarshgupta137 · 2024-07-01T13:12:58Z

Describe the bug

Most nix commands which require building are not working on darwin anymore after upgrading to nix 2.23.1

Steps To Reproduce

Run any nix command such as darwin-rebuild, home-manager, nix flake run etc. which tries to trigger a build.

Error on darwin-rebuild switch:

error:
       … while setting up the build environment

       error: getting status of '/private/tmp/nix-build-builder.pl.drv-0/build': Permission denied

Error on home-manager switch:

       … while realising the context of path '/nix/store/v2m51qlv1l2ipahav76bj4j20j946qdh-default-conf.json'

       … while setting up the build environment

       error: getting status of '/private/tmp/nix-build-default-conf.json.drv-0/build': Permission denied

Expected behavior

No errors. I'm unable to use any nix commands which trigger a build

nix-env --version output

nix-env (Nix) 2.23.1

Additional context

The culprit seems to be: 20ac781.
My nix config: https://github.com/utkarshgupta137/nix-config/
P.S. I've enabled nix.settings.sandbox

Priorities

Add 👍 to issues you find important.

The text was updated successfully, but these errors were encountered:

utkarshgupta137 · 2024-07-01T13:51:32Z

Found a fix:

cd /etc/nix
sudo mv nix.conf nix.conf1
sudo cp nix.conf1 nix.conf
sudo vi nix.conf => change sandbox = true to sandbox = false
sudo launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
sudo launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist
sudo rm nix.conf
sudo mv nix.conf1 nix.conf

Basically, these are the steps to manually change nix.conf & reload nix-daemon. We also need to undo changes to nix.conf, so that darwin-rebuild can update them.
I would recommend changing your conf to set nix.settings.sandbox to false, until this is fixed.
Alternatively, if your user is a trusted-user, you can do darwin-rebuild switch --option sandbox false.

Leaving it open till sandbox option is fixed on darwin.

emilazy · 2024-07-01T18:55:37Z

Seeing this on 2.18.4 too; seems like it must be caused by the recent Linux security fix: 2.18.3...2.18.4. Ironically this regresses the sandboxing on Darwin.

emilazy · 2024-07-01T18:58:15Z

I believe relaxing the read permissions on the build parent directory, at least on macOS, would address this.

Edit: Although actually I have no idea why the sandbox would affect things in that case. I’ll have to dig into this more another day.

Edit edit: Oh, it’s because useChroot logic is followed even though the macOS sandbox doesn’t use chroot.

emilazy · 2024-07-01T19:04:10Z

I will try to fix this tomorrow.

Issue: NixOS/nix#11002

uncenter · 2024-07-02T23:09:51Z

Found a fix:

Thank you @utkarshgupta137! Worked flawlessly for me, disabled sandboxing right away!

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114)

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114)

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114)

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114) (cherry picked from commit 9feee13)

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114) (cherry picked from commit 9feee13)

@alois31

The recent fix for CVE-2024-38531 broke the sandbox on macOS completely. As it’s not practical to use `chroot(2)` on macOS, the build takes place in the main filesystem tree, and the world‐unreadable wrapper directory prevents the build from accessing its `$TMPDIR` at all. The macOS sandbox probably shouldn’t be treated as any kind of a security boundary in its current state, but this specific vulnerability wasn’t possible to exploit on macOS anyway, as creating `set{u,g}id` binaries is blocked by sandbox policy. Locking down the build sandbox further may be a good idea in future, but it already has significant compatibility issues. For now, restore the previous status quo on macOS. Thanks to @alois31 for helping me come to a better understanding of the vulnerability. Fixes: 1d3696f Closes: #11002 (cherry picked from commit af2e114) (cherry picked from commit 9feee13)

utkarshgupta137 added the bug label Jul 1, 2024

utkarshgupta137 changed the title ~~nix broken on darwin after patch for GHSA-q82p-44mg-mgh5~~ [2.23.1] nix sandbox broken on darwin Jul 1, 2024

Eliot00 added a commit to Eliot00/NixOSConfig that referenced this issue Jul 2, 2024

fix: nix sandbox broken on darwin

05c2c08

Issue: NixOS/nix#11002

roberth added macos Nix on macOS, aka OS X, aka darwin regression Something doesn't work anymore labels Jul 3, 2024

emilazy mentioned this issue Jul 3, 2024

libstore: fix sandboxed builds on macOS #11031

Merged

roberth closed this as completed in af2e114 Jul 5, 2024

roberth closed this as completed in #11031 Jul 5, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[2.23.1] nix sandbox broken on darwin #11002

[2.23.1] nix sandbox broken on darwin #11002

utkarshgupta137 commented Jul 1, 2024 •

edited

Loading

utkarshgupta137 commented Jul 1, 2024 •

edited

Loading

emilazy commented Jul 1, 2024

emilazy commented Jul 1, 2024 •

edited

Loading

emilazy commented Jul 1, 2024

uncenter commented Jul 2, 2024 •

edited

Loading

[2.23.1] nix sandbox broken on darwin #11002

[2.23.1] nix sandbox broken on darwin #11002

Comments

utkarshgupta137 commented Jul 1, 2024 • edited Loading

utkarshgupta137 commented Jul 1, 2024 • edited Loading

emilazy commented Jul 1, 2024

emilazy commented Jul 1, 2024 • edited Loading

emilazy commented Jul 1, 2024

uncenter commented Jul 2, 2024 • edited Loading

utkarshgupta137 commented Jul 1, 2024 •

edited

Loading

utkarshgupta137 commented Jul 1, 2024 •

edited

Loading

emilazy commented Jul 1, 2024 •

edited

Loading

uncenter commented Jul 2, 2024 •

edited

Loading