Author of the submitted article here. Your write-up was one of many I went through when I first stumbled upon sandbox-exec and it was tremendously helpful, so thank you. I believe it should also be linked from the blog post I made. The main reason I wrote a separate blog post instead of adding a few bookmarks here and there is that I use my blog as open lab notes. It's easy to find and go back to ideas I've previously visited, and also to find references for more sources if I need to dig deeper into something.
oh, yeah, sandbox-exec is fun. for the record, the exact scheme they use is tinyscheme. the whole facility is largely undocumented, but it still somehow manages to be friendlier than seccomp -- i remember learning about it in a talk on the nix macos effort
The macOS sandbox isn't "deprecated", but it's treated as an internal detail of the OS subject to change without warning. Maybe the message is intended to warn people away from using the "sandbox-exec" tool?
Periodically some third-party software will inadvisedly try to use sandbox-exec and encounter problems when the policy changes. Some examples I've run into with Bazel:
It's might be worth to note that Apple is now using Bazel internally and have an active engineering team working on Bazel-related projects. So I would hope if they were to have any bone to pick with usage of `sandbox-exec` in Bazel, they would be able to introduce an alternative upstream.
Apple is large and diverse. If there is a team using Bazel internally, it is very possible that they have zero influence on what gets contributed upstream or how sandboxing is done on macOS.
> man sandbox-exec
> 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.
Reading https://developer.apple.com/forums/thread/661939, I’m fairly sure the recommended way to sandbox individual processes is to use the Endpoint Security Framework (Quinn “the Eskimo” has been with Apple for decades. I trust him to know)
(For sandboxing systems, use the Hypervisor framework or, if you want to run Linux, the Virtualization framework built on top of it)
Quinn is wrong. The recommended way for third parties to sandbox their code definitely remains the one the platform provides. That it is not considered to be stable is expected and the relationship between third party developers and Apple for this API has been consistent for at least the last decade.
Endpoint Security isn't usable for this. It's meant as a stable API for virus scanners, basically.
The sandboxing API is internal, but, Chrome uses it extensively. So Apple is limited in how much they can break it, otherwise new macOS versions can't run Chrome.
I think Apple doesn’t want third-party developers to compose their own sandboxing rules, because it’s pretty hard to do that in a way that can’t be escaped and that doesn’t break Apple’s frameworks. They provide the Mac Application Sandbox profile for third-party developers. That profile is quite flexible, and if you’re not targeting the Mac App Store there are some ways to add rule exceptions.
