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.
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.
> 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.
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.
A pretty “similar” article (in spirit?) I wrote a few years back: https://jmmv.dev/2019/11/macos-sandbox-exec.html
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.
I found your article useful and referenced it in (yet another) exploration of the sandbox here https://7402.org/blog/2020/macos-sandboxing-of-folder.html
Readers might also be interested in this script wrapper [0], which I believe was inspired by the linked blog post.
[0]: https://github.com/lynaghk/sandboxtron
We actually use this in our CI system to limit write access outside of the build environment’s build folder.
You can see some Julia code that generates the sandbox config rules here: https://github.com/JuliaCI/sandboxed-buildkite-agent/blob/ma...
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
you can “enjoy” the sight of some c++ directly generating scheme here: https://github.com/NixOS/nix/blob/2.9.2/src/libstore/build/l...
Do you happen to have a link to the talk about Nix on macOS you heard about it from? Or event the title/details so I could search?
here: https://www.youtube.com/watch?v=73mnPBLL_20
be warned, it's from 2017, so there are 5 years of history you'll still need to go looking for
This is a confusing title because “App Sandbox” is the name of the (somewhat different) sandboxing and container mechanism used by, well, apps.
LGTM. Is it really deprecated?
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:
https://github.com/bazelbuild/bazel/issues/10068
https://github.com/bazelbuild/bazel/issues/13766
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.
No. It’s the recommended way to sandbox software on macOS. The “this is deprecated” comment is just to keep the undesirables out.
Source?
Several years of observing Apple's security team and what the largest third party sandbox clients (…browsers) are doing.
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.
As per RTFM ...
(Their all-caps, not mine)
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.
Can this provide something like linux’s unshare?