Thanks, I was wrong to say seatbelt had been deprecated, it's just sandbox-exec
This stuff is so frustrating though! If your sandboxing mechanism requires you to be "an expert in macOS internals" it's not going to get used often, and the people who DO use it are liable to make mistakes.
Clear documentation and a great developer experience are, in my opinion, essential for sandboxing mechanisms - and most of them don't have that.
Hm, OK. Is there some reason that dev containers and running agents inside it won't work? I've been looking at AI sandboxing lately and can't quite decide if there's really a problem to solve here, or whether giving the agent a container regardless of platform is what makes the most sense. I guess it depends on whether you're developing apps that can run containerized - most devs do I imagine, but if you're writing mobile or desktop apps then a different strategy would be needed.
I've tried a whole bunch of things. I'm currently using Docker for Desktop and running containers in that, which is OK but feels like a LOT of overhead to address a problem that the core OS has features for solving already.
I want a solution I can distribute to other people where the first step isn't "install Docker".
Ah, you mean for sandboxing an agent that isn't meant to be used by developers? Apple is adding containers support to the core OS now. So for developers, it seems like it won't be difficult for them soon and agent software can manage the dev container instances. For a native Mac app you can embed one inside another and the latter can have a more restrictive set of App Sandbox entitlements.
The main reasons to prefer a Linux container are:
• The agent can install new software packages if it needs them. If you use a native Mac sandbox then it'd need to ask permission to use homebrew. Maybe you can find a way to run homebrew inside a Mac sandbox but it won't be straightforward.
• Simpler boundary. The bug I reported (in an AI agent sandbox using Seatbelt) was that it failed to properly block off access to the user's home directory dotfiles and ~/Library. This sort of mistake is easy to make with Seatbelt but harder to make with containers. There are many other sandbox escapes in the policy I saw. Note that using Apple's standard sandbox APIs would avoid this type of error.
• You can edit the SSL root store for just the agent, meaning you can MITM traffic from the agent to the internet. Doing that with native Mac apps isn't possible unless the user actually modifies the root store, which they may not want to do.
Apple do have those things! People just like bypassing it :) For the AI use case that you're interested in, there are ways to do this that go with Apple's flow, but UNIX hackers tend to be attracted to sandbox-exec because it looks simple even though it's not, and because doing it Apple's way requires learning a lot of Apple specific tech. Whereas the SBPL is deceptively UNIXy and simple looking.