“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 wonder how many major applications and tools depend on sandbox-exec today despite that depreciation, IIRC I can think of the Codex CLI and Swift Package Manager.
I don’t know if there are problems with this tool, but the App Sandbox is very configurable and every app store app is in one. It doesn’t make sense to maintain two different complex sandboxing solutions.
alias sandbox-no-network='sandbox-exec -p "(version 1)(allow default)(deny network*)"'
pro-tip on alias:
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.
It weirds me out a bit that Claude is able to reach outside the sandbox during a session. According to the docs this is with user consent. I would feed better with a more rigid safety net, which is why I've been explicitly invoking claude with sandbox-exec.
It drives me nuts that sandbox-exec has "sandbox" in the name, since it's nothing like a real sandbox, and much closer to something like a high-level seccomp, and not much to do with "App Sandboxes" which is a distinct macOS feature.
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.
What you're describing is a resource virtualization with transactional reconciliation instead of program isolation in the mediation sense (MAC/seccomp-style denial).
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.
> 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.
You'll want to look into Homebrew (or Macports) for access to the larger world
I like this! I built something similar for sandboxing CLI agents, and in the repo have a collection of minimal profiles for sandbox-exec to use - https://agent-safehouse.dev/
I’m impressed really neat work! Why did you opt for closed source?
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
I'd add one warning for folks who haven't used it before: a tiny typo in the profile can turn into confusing runtime failures later, far away from the command that triggered them. The tool is useful, but the feedback loop is rough.
Do any of the third-party package managers (Brew, MacPorts) perhaps use this for things like builds (or even installs, if things are restricted to (e.g.) /opt)?
I’ve written a personal system in Common Lisp for building third-party software on macOS (coincidentally somewhat similar to GUIX), and I use sandbox-exec to isolate execution so that only intended requisites affect the build process and so that installation is strictly confined to the configured destination directory, no scribbling outside the lines.
Technically, it’s not just Scheme-like but literally a Scheme interpreter (TinyScheme). However, the Scheme isn’t being executed to make individual sandboxing decisions. It’s just executed once while parsing the config, to build up a binary sandbox definition which is what the kernel ultimately uses to make decisions (using a much more limited-purpose, non-Turing-complete execution engine).
I believe GUIX is implemented in Scheme which makes Scheme a natural choice for expressing configuration. Lisp tend to be a natural configuration format for anything written in Lisp. Highly functional configuration processing comes practically for free.
Although macOS do provide many little known useful tools (besides this, there’s also dtrace, pf, etc), I still run a Linux VM in my MacBook for daily work. Thing is, the effort I spend on learning these tools is almost wasteful unless I’m doing iOS or macOS development. Skills about Linux tools however, is something people considered valuable because of its wider application. I think apple is missing opportunities by not doing more about macOS Server platform.
“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.
You can spoof or disappear a mashed file. You can trigger vulnerabilities by breaking internal assumptions of a program.
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.
- https://developers.openai.com/codex/security/#os-level-sandb...
- https://code.claude.com/docs/en/sandboxing
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.
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.
You'll want to look into Homebrew (or Macports) for access to the larger world
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
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
I think Bazel uses sandbox-exec on macOS.
https://developer.apple.com/documentation/security
Writing a parser for Lisp S-expressions is dead-simple, I wonder if that's why they used the format.