“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.
Basically everyone who has to care about security on the Mac.
If you are using "sandbox-exec" then you are likely maintaining your own seatbelt profile. Keeping those up to date can be challenging, especially for 3rd parties as any changes to underlying Frameworks and libraries can break a hand crafted profile.
If you are using it to secure your own stuff and accept this and not complain, even for minor SW updates, then you are going to be fine. Don't ship things to 3rd parties without also accepting this. That is what this deprecated means.
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.
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.
https://developer.apple.com/forums/thread/124284
:-)
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.
I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.
[] a GUI app can restore access to files by using a trusted external selection process.
alias sandbox-no-network='sandbox-exec -p "(version 1)(allow default)(deny network*)"'
for sh-compliant shells, including a whitespace at the end of the alias string causes the next token to also go through alias expansion. (maybe it would also be a hint to the shell for tab completion as well). This is a perfect example of when, where, and why you would want to do that.
edit: I don’t have a problem with closed source, but when software is expected to be accountable for my security I get a little paranoid, so was curious about the safety and guarantees here. The UX and everything else looks great
- https://developers.openai.com/codex/security/#os-level-sandb...
IMO a real sandbox let's a program act how it wishes without impacting anything outside the sandbox. In reality many of these tools just cause hard failures when attempting to cross the defined boundaries.
It's also poorly documented and IIRC deprecated. I don't know what is supposed to replace it.
If macOS simply had overlay mounts in a sandbox then it would unlock so much. Compared to Linux containers (docker, systemd, bubblewrap, even unshare) macOS is a joke.
The App Sandbox is literally Seatbelt + Cocoa "containers". secinitd translates App Sandbox entitlements into a Seatbelt profile and that is then transferred back to your process via XPC and applied by an libsystem_secinit initializer early in the process initialization, shortly before main(). This is why App Sandbox programs will crash with `forbidden-sandbox-reinit` in libsystem_secinit if you run them under sandbox-exec. macOS does no OS-level virtualization.
An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:
(when (entitlement "com.apple.security.files.downloads.read-only")
(read-only-and-issue-extensions (home-subpath "/Downloads")))
(when (entitlement "com.apple.security.files.downloads.read-write")
(read-write-and-issue-extensions (home-subpath "/Downloads")))
(when (or (entitlement "com.apple.security.files.downloads.read-only")
(entitlement "com.apple.security.files.downloads.read-write"))
(allow process-exec (home-subpath "/Downloads")))To let a program act as it wishes, ideally every security-relevant mutable resource must be virtualized instead of filtered. Plus, FS is only one of the things that should be sandboxed. You should also ideally virtualize network state at least, but ideally also process/IPC namespaces and other such systems to prevent leaks.
You need to offer a promotion step after the sandbox is over (or even during running if it's a long-running program) exposing all sandbox's state delta for you to decide selective reconciliation with the host. And you also must account for host-side drift and TOCTOU hazards during validation and application
I'm experimenting with implementing such a sandbox that works cross-system (so no kernel-level namespace primitives) and the amount necessary for late-bound policy injection, if you want user comfort, on top of policy design and synthetic environment presented to the program is hair-pulling.
Curious, if this is cross-platform, is your design based on overriding the libc procedures, or otherwise injecting libraries into the process?
Also obligatory https://xkcd.com/2044/
- controls which files the process can read and write
- controls what network access the process is allowed
You'll want to look into Homebrew (or Macports) for access to the larger world
Readers may also be interested in <https://github.com/eugene1g/agent-safehouse> which was open sourced after a recent HN conversation <https://news.ycombinator.com/item?id=46923436>.
https://github.com/obra/packnplay
https://github.com/strongdm/leash
https://github.com/lynaghk/vibe
(I've been collecting different tools for sandboxing coding agents)
https://github.com/eugene1g/agent-safehouse via CGamesPlay
https://multitui.com/ via davidcann
- https://github.com/jingkaihe/matchlock
- https://github.com/mishushakov/libkrun-go
- https://github.com/earendil-works/gondolin
- https://github.com/butter-dot-dev/bvisor
- https://github.com/amlalabs/amla-sandbox
- https://github.com/eryx-org/eryx
- https://github.com/containers/bubblewrap (not new)
- https://github.com/coplane/localsandbox
- https://github.com/sd2k/conch
- https://github.com/Gerharddc/litterbox
- https://github.com/finbarr/yolobox
- https://github.com/coventry/sandbox-codex
- https://github.com/osks/ctenv
- https://github.com/tianon/gosu
- https://github.com/colony-2/shai
- https://github.com/rcarmo/agentbox
- https://github.com/coder/httpjail
- https://github.com/bytecodealliance/componentize-py
- https://github.com/tursodatabase/agentfs
- https://github.com/always-further/nono
- (another list on HN Deno Sandbox: https://news.ycombinator.com/item?id=46876022)
- Did not check if any/all of these are here: https://github.com/arjan/awesome-agent-sandboxes
- Announce that they are no longer going to deprecate sandbox-exec and instead publish detailed documentation for it
- Add a reliable "select all" option to the iOS copy/paste menu
The features you're describing would not buy them credibility in the AI field anyhow. They would certainly plaster over some of macOS and iOS' more embarrassing limitations, but professional AI deployments are not hamstrung by those limits. It's just the commodity homelabbers who want to brag about buying a 120gb GPU with anemic compute performance. Apple doesn't need to curry favor with those people, they'd buy the hardware for the luls regardless of what the software experience is like.
You can spoof or disappear a mashed file. You can trigger vulnerabilities by breaking internal assumptions of a program.
I think Bazel uses sandbox-exec on macOS.
Writing a parser for Lisp S-expressions is dead-simple, I wonder if that's why they used the format.
For development you usually don’t need a kernel policy language - you mostly want: 1. builds not trashing your real $HOME 2. no dotfiles/config pollution 3. some basic separation if a project does something dumb
A much simpler (and more reliable) alternative on macOS is just a dedicated throwaway user account. macOS already isolates home directories, keychains, and app state per-user, so you get a practical sandbox without fighting SBPL quirks or mysterious denials.
My workflow now: I have a user called rsh. I clone and build everything there. My real home directory stays clean. If a project goes crazy, it only damages /Users/rsh
It also avoids the “1000 hidden files in your home folder” problem that a lot of language ecosystems cause.
Minimal setup :
sudo sysadminctl -addUser rsh -password $(LC_ALL=C tr -dc A-Za-z0-9 </dev/urandom | head -c 16); sudo dseditgroup -o edit -d rsh -t user admin || true; sudo install -d -m 755 -o rsh -g staff /Users/rsh/projects
Then add this alias to your ~/.zshrc command:
alias rsh='sudo -iu rsh /bin/zsh -l'
After that I just run rsh, clone repos into ~/projects, and build there.
Cloning them there means leaving access to your SSH keys, right?
It would be fine if Apple was providing the APIs, docs and support to stimulate 3rd party tools. Hyperkit sat undocumented for 15+ years until a proper hypervisor platform was built on top of it. This sandboxing framework is another example.
Wow this is cool
who looks at it and goes "yes, ill upvote this. more people should see it."?