Comment by simonw

> All I want is an easy, documented, supported way to run a binary on my computer and say "it can only access these files, use this much RAM and it's not allowed to make any outbound network requests". It always surprises me how hard this is!

I think that if the operating system (and the computer design too) were designed better, then I think that it might be possible to do that, and other things (e.g. all outbound network requests must go through a specified proxy without the program knowing of the proxy, or must use a specific network interface, etc).

> Maybe the new "containers" stuff in macOS 26 is going to be a good replacement for that?

It is not. The Containerization framework [1] is, in its own words, "a Swift package for running Linux containers on macOS" - it's more or less an Apple-branded Docker runtime. It's not applicable to macOS software.

[1]: https://github.com/apple/containerization

macOS already has a way to do that if you're a developer, but it's weirdly both obvious and non-obvious enough that people don't seem to use it: just compile a simple program that executes other programs, and then sign it with the officially supported sandbox entitlements. You will need a supervisor program that starts up the sandboxed sub-process and grants it access to the needed files via the official bookmarks API (that's what it's called):

https://developer.apple.com/documentation/security/accessing...

Now you're wondering why this isn't built in to the OS. But it is! Apps from the Mac App Store are always sandboxed. Just get your apps from there, and now you know what permissions they need because the store can tell you, as can the Settings app. You can even toggle permissions on and off via Settings.

macOS has the best sandbox of any desktop OS by far. Seatbelt isn't actually deprecated and never has been. Marking it as such seems to be just a way to warn developers off trying to use it directly. Nonetheless, it's not going anywhere: Chrome's sandbox relies on it heavily and if Apple tried to remove it or even just break backwards compatibility with it they'd break Chrome, and if not done in a coordinated manner that'd open up a lot of nasty lawsuit potential and corporate relationship problems.

The reason Apple don't want you using Seatbelt directly is that you have to be an expert in macOS internals to use it correctly ... and those internals change with every release. I reported a vulnerability to a well known company just a couple of weeks ago that involved them using Seatbelt wrong! Apple's entitlements wrap up a common set of use cases under a stable API and it's then on Apple to keep them working correctly as the internals move around.

It mostly seems to be deprecated to encourage developers to use App Sandbox rather than doing custom sandboxing things. With custom sandboxing baking implementation details of system frameworks into the sandbox policy is almost unavoidable, and Apple would really rather you didn't do that as it limits their ability to make changes in the future.

The underlying sandbox subsystem is what App Sandbox uses. Apple can happily rely on implementation details of system frameworks in their policies because they can update them as the system frameworks change.

The sandbox subsystem is what all of Apple's system software uses for sandboxing, as well as many security-conscious third-party programs such as web browsers. It's not going anywhere anytime soon, despite being marked as deprecated.

You want a capability based OS where by default processes are sandboxed.

I use Docker for this. Sandbox is not effective. Like if you run Firefox with "deny network" profile you will still be able to browse as usual.

The ideal for me would be Asahi support from Apple, but the software support on their hardware is so far behind the hardware itself (which is amazing).

Agreed, macOS has lagged every other OS here.

The easiest solution is to give up and use Linux (Docker).