https://man.freebsd.org/cgi/man.cgi?query=sandbox-exec&aprop...:
“The sandbox-exec command is DEPRECATED. Developers who wish to sandbox an app should instead adopt the App Sandbox feature described in the App Sandbox Design Guide”
That still is the case for MacOS 26.3 (https://man.freebsd.org/cgi/man.cgi?query=sandbox-exec&aprop...)
MacOS 10.13.6 is from 2017, so this has been deprecated for almost 10 years.
I wonder how many major applications and tools depend on sandbox-exec today despite that depreciation, IIRC I can think of the Codex CLI and Swift Package Manager.
Claude, Firefox, safari, chrome, etc etc etc etc
Basically everyone who has to care about security on the Mac.
Bazel as well.
and Homebrew!
Does anyone have any details regarding the deprecation? I wonder why Apple made this decision.
There’s not that much detail. A few comments in 2019 from a DTS person indicated that Apple didn’t really anticipate people shipping on this in volume. My guess is they want to dissuade people from using it.
They can’t immediately just do away with it because a bunch of their first party apps use it (entitlements don’t cut it). It’s a weird space.
> a DTS person
Quinn the Eskimo, no doubt. I'm convinced he or she is the only actual human being providing developer technical support at Apple. Certainly the only one I've ever successfully communicated with. Support tickets go to robots who are incapable of providing relevant answers. Maybe Quinn is an alias with a team of humans behind it, but I don't think so. I've had him or her take forum posts to private e-mail and it does seem like a single person.
Unfortunately, even Quinn is fully at the mercy of Apple's internal bureaucracy, which is quite formidable.
Not the only one, but the most prolific that’s for sure.
Yeah, it was Quinn. I didn’t want to name them and seem too knowing haha.
It's not much of a giveaway. Quinn is the most likely respondent to questions on https://developer.apple.com/forums/ for years now, including this one about sandbox-exec in 2019:
https://developer.apple.com/forums/thread/124284
:-)
I don’t know if there are problems with this tool, but the App Sandbox is very configurable and every app store app is in one. It doesn’t make sense to maintain two different complex sandboxing solutions.
App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.
By far the biggest advantage of App Sandbox is that the policy ships along with the OS. If a system framework changes what resources it accesses in a software update, Apple can update the policy so the framework functionality still works. If your app uses a custom sandbox policy, you're on your own to both notice that something has changed and to update your policy.
The downside is that the App Sandbox policy is limiting and inflexible.
That’s not true. Lots of apple’s own first party apps use SBPL to sandbox because the entitlement granularity doesn’t cut it. There’s also lots of apps on the MAS which use temporary-exception SBPL to fully sandbox.
I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.
If swift package manager is using it (I believe it is based on some of the error messages I occasionally see from it), deprecating it is difficult, since SPM is not distributed as an App Store app.
Meh, cron on OS X/macOS has been deprecated for over 20 years.
And its binary is banned on certain macOS installations. I have two identical mac minis with the very same OS version. On one cron runs, on the other the cron binary doesn't run (killed: 9) even if I re-sign the binary in different location with my own codesigning identity. It's that banned.
[dead]