"sandbox_apply_container: Operation not permitted" error with xcodebuild and Swift package dependencies

[p00ya]

I noticed a recent regression with a formula I maintain (p00ya/tap/vivtool). I get an error from brew install like:

xcodebuild: error: Could not resolve package dependencies:
  sandbox-exec: sandbox_apply_container: Operation not permitted

In the system console, there'll be an entry like:

deny(1) forbidden-sandbox-reinit

These errors indicate that a process that is already sandboxed is calling sandbox-exec. The macOS sandbox doesn't nest, so this leads to an error. This only happens when building in homebrew's build environment; running the same xcodebuild command from a clean checkout of the repo has no error.

To figure out what was calling sandbox-exec, I built the formula with homebrew's debug mode, created my own sandbox-exec binary (purely for the purpose of debugging this one issue - obviously it's a bad idea in general) and traced through the process chain that leads to this:

/usr/local/Homebrew/Library/Homebrew/brew.rb install p00ya/tap/vivtool -d
/usr/local/Homebrew/Library/Homebrew/build.rb /usr/local/Homebrew/Library/Taps/p00ya/homebrew-tap/vivtool.rb --debug
/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -project vivian.xcodeproj -scheme vivtool -configuration Release clean install DSTROOT=build SYMROOT=/private/tmp/vivtool-20201014-79440-1gak296/build
/Applications/Xcode.app/Contents/SharedFrameworks/XCBuild.framework/Versions/A/PlugIns/XCBBuildService.bundle/Contents/MacOS/XCBBuildService
/Users/brewroot/bin/sandbox-exec -p (version 1)\012(deny default)\012(import "system.sb")\012(allow file-read*)\012(allow process*)\012(allow sysctl*)\012(allow file-write*\012    (regex #"^/private/var/tmp/org\.llvm\.clang.*")\012    (regex #"^/private/tmp/org\.llvm\.clang.*")\012    (regex #"^/private/var/folders/fn/9l_y23q95bl543xfk2mz49ww0000gp/T/org\.llvm\.clang.*")\012    (regex #"^/private/var/folders/fn/9l_y23q95bl543xfk2mz49ww0000gp/C/org\.llvm\.clang.*")\012    (subpath "/Users/brewroot/Library/Developer/Xcode/DerivedData/vivian-fykeuamgbuajcngfhibsupwkzxpe/SourcePackages")\012)\012 /private/tmp/TemporaryDirectory.NxKuw7/swift-argument-parser-manifest -fileno 20

So what's happening is that as part of building a swift package dependency, xcodebuild will compile and run a manifest file from that package, but will wrap the call in sandbox-exec so it doesn't do anything nefarious as part of building. Unfortunately, when building with homebrew (and only then), there is already a sandbox at a higher level, so this fails. I'm not exactly sure where the initial sandbox is getting created - I can still repro by repeating the xcodebuild command from the shell I get with install -d, but the shell itself doesn't seem restricted.

I think maintainers of formulae for actual Swift packages have been dealing with a similar issue by passing --disable-sandbox to swift, e.g. this SwiftLint commit, and indeed many formulae in homebrew-core. But no such option exists for xcodebuild.

I think fixing this behaviour properly requires some intervention from Apple (I suspect something in the homebrew environment or shims is causing xcodebuild to run sandboxed, in which case it shouldn't be calling subprocesses with sandbox-exec). Other potential Apple-dependent solutions would be to make their sandbox nest (restrictions get tighter), or to have a flag on xcodebuild similar to swift's --disable-sandbox.

In the meantime, the most pragmatic solution I can find that I can perform as a formula maintainer is to do the same thing I did for debugging: create a sandbox-exec replacement and put it on the PATH during the homebrew build. I do worry that this is fragile (I'm surprised Apple didn't hardcode /usr/bin/sandbox-exec in the first place), but at least that means users can install the package.

Has anyone else encountered this / have a better solution?

[p00ya]

Here's my workaround:

p00ya/homebrew-tap@6a07348

I should also add that I suspect an upgrade from Xcode 11.x to Xcode 12 triggered the regression, though I haven't reverted back to Xcode 11.x to check that. It could also have been a macOS or homebrew upgrade.

[Frizlab]

Well it seems this workaround does not work anymore sadly.
I tried with Xcode 12.5 (12E262) and could not get rid of the sandbox error.

[Frizlab]

BTW the original sandbox is created by Homebrew itself. (You can see the sandbox-exec call when installing the formula in verbose mode.)

[SMillerDev]

I think this should really be a Apple bugreport. There is nothing homebrew can do short of disabling sandboxing, which isn't gonna happen.

[p00ya]

Yep I agree this should get escalated to Apple, though someone who understands how Homebrew influences xcodebuild to run in a sandbox may be better placed for this (FWICS it doesn't seem to be the mechanism in brew/Library/Homebrew/sandbox.rb - there's no outer sandbox-exec in the process tree).

Homebrew can do something similar to my workaround, which isn't as drastic as completely disabling sandboxing: it only prevents the inner sandbox from being created (and even then it will only do so if the sandbox really isn't available). Realistically, any solution will have to do this (and it's no worse than all those swift formulae in homebrew-core doing --disable-sandbox already).

[carlocab]

Creating a shim for sandbox-exec that just bypasses creating the sandbox might be something we can do in brew. The shim might even look a lot like your workaround, if you don't mind opening a PR for it.

[dteirney]

@p00ya , @carlocab , I just ran into this issue trying to install https://github.com/samuelmeuli/tmignore via brew. What's the next step for this issue? Is there someone from the Homebrew team that has a contact in Apple to get some guidance from? Or is a shim the preferred option? And, if so, @p00ya do you have any availability to look into that - noting that this issue was raised over 6 months ago so you might have moved onto other things?

[p00ya]

1. sandbox-exec is deprecated (checked on macOS 12.2.1, see its manpage).
2. Homebrew continues to use it (checked on 3.3.16).
3. Apple's xcodebuild also continues to use it (checked on 13.2.1).
4. My workaround stopped working, probably because Apple did the reasonable thing of ignoring the user PATH when calling sandbox-exec, but I haven't confirmed. This also means that just changing the shims within Homebrew will not be enough either.

I doubt the Darwin team will prioritize a fix to sandbox-exec, given that they deprecated it already and the vast majority of macOS users aren't affected. That said, I think Homebrew is still justified in using sandbox-exec: it protects users from formulae doing evil things, and the recommended replacement for sandbox-exec (App Sandbox) isn't an option with the way Homebrew runs (a ruby interpreter exec()ing arbitrary build tools). Apple fixing sandbox-exec to be re-entrant is still the best option from a user's point of view.

While the Darwin team may not empathize with the situation, maybe the Xcode folks will? Adding a -disable-sandbox option to xcodebuild (or have it autodetect if it's already in a sandbox) seems like it should fly, especially given Swift has such an option.

In both these cases, the Homebrew maintainers like @SMillerDev should be the ones reaching out to Apple, so they can provide justifications about the design decisions taken by Homebrew. I have no plans to reach out to Apple myself.

As a formula maintainer, there is no longer an easy workaround. If you maintain the upstream software getting packaged, one option is to stop using Xcode's weird hybrid package management and create a pure SPM package that you can build with swift directly, and then you can use --disable-sandbox.

There is a workaround available to the Homebrew maintainers without Apple's asssistance: giving brew a command-line option to not sandbox, something like brew install --disable-sandbox myformula. It has to be a brew option (as opposed to, say, a Formula API) because Homebrew's sandbox-exec wraps the invocation of "ruby ... build.rb" - anything in the formula itself is too late. See formula_installer.rb

There is a philosophical question here of what the actual risks are of evil formulae. brew isn't running with escalated privileges.
If you're an evil formula or upstream maintainer, you can just make your program do something evil once it's built and installed... sandboxing the formula installation itself just defers the surprise/damage.

If the Homebrew folks consent to a sandbox bypass option, I'm happy to send a PR. Probably the only folks needing it are third-party taps, so you can just tell your users how to invoke brew to bypass the sandbox.

[Frizlab]

FWIW, if by some chance some Apple folks stumble upon this, I submitted FB9099015 for re-entrant sandbox, and FB9099010 to add an option to xcodebuild to disable sandbox.

[gromgit]

There is a philosophical question here of what the actual risks are of evil formulae.

I think the primary reason for sandboxing brew installs is to trap file writes outside the formula's Cellar directory, to ensure that the bottles generated by CI builds aren't missing essential items. You'd be surprised how many open-source projects have hardcoded paths in unexpected places in their build configs; sandboxing every build surfaces this issue to be resolved.

Security concerns are a secondary consideration at best.

[p00ya]

Okay, so given the primary purpose of the sandbox is to detect accidental misbehaviour, does adding an option to disable it sound reasonable? Formula maintainers will be aware their formula is broken by default and can fix it. Packages that need the sandbox disabled can stay in third-party taps.

Another option is to move the sandbox down a level - from wrapping build.rb to the default behaviour for "system"-like methods in Formula. A formula could opt-out certain calls (e.g. unsandboxed_xcodebuild "install", ....) and brew audit can warn about such things.

[Frizlab]

Okay I know I’m bumping an old thread, but it’s become relevant again.

So for Xcode projects that use SPM there is the option -IDEPackageSupportDisableManifestSandbox=1 to xcodebuild which works well.

For Xcode projects that are using plugins (e.g. macros) though, it’s a bit more complicated. I did not find an option to xcodebuild to let it disable the sandbox for plugins. The option does exists on swift. It’s --disable-sandbox. I have actually tried compiling an SPM project that uses macros with this option in a homebrew Formula: it works.

So now my question is: would it be possible to force the --disable-sandbox to every invocation to swift using superenv? I’m not even sure it’d work, but if I wanted to test this, where should I go?

[carlocab]

So now my question is: would it be possible to force the --disable-sandbox to every invocation to swift using superenv? I’m not even sure it’d work, but if I wanted to test this, where should I go?

Yes, probably. We already have a shim for swift on Linux. We could do something similar on macOS.

Feel free to open a PR.

[Frizlab]

Well it looks like Xcode’s build system is not calling swift but /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc or /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-frontend directly so it’s probably not possible to go down this road either…