“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.
"sandbox-exec" is deprecated in the sense of "please don't use this method to run sandboxes" rather than the mechanism going away.
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.
There’s not that much detail. A few comments in 2019 from a DTS person indicated that Apple didn’t really anticipate people shipping on this in volume. My guess is they want to dissuade people from using it.
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.
It's not much of a giveaway. Quinn is the most likely respondent to questions on https://developer.apple.com/forums/ for years now, including this one about sandbox-exec in 2019:
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.
App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.
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.
That’s not true. Lots of apple’s own first party apps use SBPL to sandbox because the entitlement granularity doesn’t cut it. There’s also lots of apps on the MAS which use temporary-exception SBPL to fully sandbox.
I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.
The Sandboxing and Entitlements mechanisms are very different. Sandboxing can only drop access to resources, it cannot grant access that was not already there [1]. Entitlements are all about giving additional selective privileges or to make the sandbox NOT remove access (like full disk access or debug ability ). Entitlements are bound to processes only and are non-transferable. This is in contrast to a capability based system where they can be passed around. Reasoning about capabilities is challenging because analysis effectively requires global knowledge of the system. Binding entitlements to libraries or Frameworks would turn them into capabilities.
[1] a GUI app can restore access to files by using a trusted external selection process.
Edit: change footnote reference to prevent markup error.
This is true. I was being brash. Let me say instead that the split in reasoning and evaluation as it exists on macOS in this area is rough and potentially not needed. Granted, I don't have a better answer in my back pocket, and the fact that Apple has kicked the can for 15 years on trying to harmonize these is a sign it's hard.
If swift package manager is using it (I believe it is based on some of the error messages I occasionally see from it), deprecating it is difficult, since SPM is not distributed as an App Store app.
And its binary is banned on certain macOS installations. I have two identical mac minis with the very same OS version. On one cron runs, on the other the cron binary doesn't run (killed: 9) even if I re-sign the binary in different location with my own codesigning identity. It's that banned.
That's fascinating. I'd love to see a shasum tree of both OS installs to know if this was due to some path-dependent upgrade sequence one of the machines went through; or whether this is down to some sub-model-number hardware-component stepping issue with power efficiency or something, that only one of the machines is affected by, where the implemented launchd solution is "don't let cron run."
Why would Apple "ban" a binary they ship with the OS? If I just run /usr/sbin/cron on my Apple Silicon Mac, the output is "Killed: 9" but if I actually create a crontab for a user, it works.
See https://bdash.net.nz/posts/sandboxing-on-macos/ for more details on how sandboxing works on macOS. It touches on how the SBPL Scheme source code is interpreted in userspace to build a bytcode representation of the policy, and the kernel MAC hooks that the Sandbox kernel extension uses for enforcing sandbox policies.
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.
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
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.
> not much to do with "App Sandboxes" which is a distinct macOS feature
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.
It is a little more direct than that even. The application's entitlements are passed into the interpretation of the sandbox profile. It is the sandbox profile itself that determines which policies should be applied in the resulting compiled sandbox policy based on entitlements and other factors.
An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:
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.
> 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?
I'm not interposing libc or injecting libraries. Guests run as WASM modules, so the execution substrate is constrained. The host mediates and logs effects. Changes only propagate via an explicit, policy-validated promotion step.
> 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'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.
"If" indeed. Apple has a trillion-dollar AI market staring themselves in the face, and they can't even find it in them to sign CUDA drivers for their own good.
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.
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.
I went down the sandbox-exec rabbit hole recently trying to get a “safe shell” for poking at random GitHub projects. I eventually realized I was solving the wrong problem.
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.
You can tell MacOS was developed by OS nerds but stifled by product managers. There are a lot of gems like Sandboxing and Hyperkit with incredible features and practically no user interface.
Why is not spending resources to develop infrequently-used features that aren't revenue streams "stifling"? Granted, I too would love to have nice UIs for those out of the box, but > 99.9% of Mac users don't care, and 3rd-party developers can pick up the slack and maybe make some money filling the gap.
that's the short-term, MBA-style mindset to which I'm referring. Much of the popularity of MacOS came from the open source community filling that gap despite lacking support. So there is clearly demand that the PMs were not tapping into.
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.
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.
https://man.freebsd.org/cgi/man.cgi?query=sandbox-exec&aprop...:
“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.
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.
Claude, Firefox, safari, chrome, etc etc etc etc
Basically everyone who has to care about security on the Mac.
Bazel as well.
and Homebrew!
Does anyone have any details regarding the deprecation? I wonder why Apple made this decision.
"sandbox-exec" is deprecated in the sense of "please don't use this method to run sandboxes" rather than the mechanism going away.
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.
There’s not that much detail. A few comments in 2019 from a DTS person indicated that Apple didn’t really anticipate people shipping on this in volume. My guess is they want to dissuade people from using it.
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.
> a DTS person
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.
Yeah, it was Quinn. I didn’t want to name them and seem too knowing haha.
It's not much of a giveaway. Quinn is the most likely respondent to questions on https://developer.apple.com/forums/ for years now, including this one about sandbox-exec in 2019:
https://developer.apple.com/forums/thread/124284
:-)
Not the only one, but the most prolific that’s for sure.
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.
App Sandbox is fundamentally a way for programs to use the underlying sandbox subsystem without having to write SBPL code themselves. When a program has opted into the App Sandbox, the system applies one of these sandbox policies automatically during app initialization. The policy examines the entitlements of the application to determine which additional resources should be permitted. See /System/Library/Sandbox/Profiles/application.sb if you're curious.
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.
That’s not true. Lots of apple’s own first party apps use SBPL to sandbox because the entitlement granularity doesn’t cut it. There’s also lots of apps on the MAS which use temporary-exception SBPL to fully sandbox.
I agree that there is no sense in operating dual systems, but entitlements can’t replace SBPL yet.
The Sandboxing and Entitlements mechanisms are very different. Sandboxing can only drop access to resources, it cannot grant access that was not already there [1]. Entitlements are all about giving additional selective privileges or to make the sandbox NOT remove access (like full disk access or debug ability ). Entitlements are bound to processes only and are non-transferable. This is in contrast to a capability based system where they can be passed around. Reasoning about capabilities is challenging because analysis effectively requires global knowledge of the system. Binding entitlements to libraries or Frameworks would turn them into capabilities.
[1] a GUI app can restore access to files by using a trusted external selection process.
Edit: change footnote reference to prevent markup error.
This is true. I was being brash. Let me say instead that the split in reasoning and evaluation as it exists on macOS in this area is rough and potentially not needed. Granted, I don't have a better answer in my back pocket, and the fact that Apple has kicked the can for 15 years on trying to harmonize these is a sign it's hard.
If swift package manager is using it (I believe it is based on some of the error messages I occasionally see from it), deprecating it is difficult, since SPM is not distributed as an App Store app.
Meh, cron on OS X/macOS has been deprecated for over 20 years.
And its binary is banned on certain macOS installations. I have two identical mac minis with the very same OS version. On one cron runs, on the other the cron binary doesn't run (killed: 9) even if I re-sign the binary in different location with my own codesigning identity. It's that banned.
That's fascinating. I'd love to see a shasum tree of both OS installs to know if this was due to some path-dependent upgrade sequence one of the machines went through; or whether this is down to some sub-model-number hardware-component stepping issue with power efficiency or something, that only one of the machines is affected by, where the implemented launchd solution is "don't let cron run."
Why would Apple "ban" a binary they ship with the OS? If I just run /usr/sbin/cron on my Apple Silicon Mac, the output is "Killed: 9" but if I actually create a crontab for a user, it works.
See https://bdash.net.nz/posts/sandboxing-on-macos/ for more details on how sandboxing works on macOS. It touches on how the SBPL Scheme source code is interpreted in userspace to build a bytcode representation of the policy, and the kernel MAC hooks that the Sandbox kernel extension uses for enforcing sandbox policies.
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.
I made a UI for this to run terminal apps, like claude and codex: https://multitui.com
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/
Codex already uses sandbox-exec on macOS :)
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
Which terminal do you embed?
Wow, this looks very nice.
Both Claude Code and Codex use sandbox-exec with Seatbelt to sandbox execution:
- https://developers.openai.com/codex/security/#os-level-sandb...
- https://code.claude.com/docs/en/sandboxing
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.
> not much to do with "App Sandboxes" which is a distinct macOS feature
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.
It is a little more direct than that even. The application's entitlements are passed into the interpretation of the sandbox profile. It is the sandbox profile itself that determines which policies should be applied in the resulting compiled sandbox policy based on entitlements and other factors.
An example from /System/Library/Sandbox/Profiles/application.sb, the profile that is used for App Sandboxed applications, on my system:
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.
> 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/
I'm not interposing libc or injecting libraries. Guests run as WASM modules, so the execution substrate is constrained. The host mediates and logs effects. Changes only propagate via an explicit, policy-validated promotion step.
Sandbox-exec covers everything I personally expect from a sandbox:
- controls which files the process can read and write
- controls what network access the process is allowed
> 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
They are discussing a Linux kernel feature. Docker/Podman on macOS launch a virtual machine to function.
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.
Thanks for putting this together, it's very helpful.
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>.
See also:
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)
And from this thread I also see:
https://github.com/eugene1g/agent-safehouse via CGamesPlay
https://multitui.com/ via davidcann
I've been collecting a list of sandboxing related projects as well, some lower level than others. I wish I had time to evaluate them all:
- 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
Got a weird one https://github.com/Protonk/PAWL
If there is a gui i can deploy custom browsers for classroom for labbing !
This tool is not just used for safety. ;)
You can spoof or disappear a mashed file. You can trigger vulnerabilities by breaking internal assumptions of a program.
If Apple wanted to win back some serous credibility in the AI field there are two very low hanging fruit that they could use:
- 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
Apple is going to Apple. They're as likely to remove the deprecation as they are to restrict it to first party apps only. They don't care about devs.
"If" indeed. Apple has a trillion-dollar AI market staring themselves in the face, and they can't even find it in them to sign CUDA drivers for their own good.
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.
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)?
Homebrew uses sandbox-exec during builds and installs, yeah. To my memory we’ve used it for at least 6 or 7 years, probably longer.
Nix uses the underlying libsandbox function for builds: https://github.com/NixOS/nix/blob/614072adcb56202f0a09532971...
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.
I think Bazel uses sandbox-exec on macOS.
Nice write-up! This is one component of a much larger umbrella framework for security on Apple platforms:
https://developer.apple.com/documentation/security
Interesting config used a Scheme-like format. Any ideas on how that came to be?
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).
Do we know that engine is not Turing-complete for sure?
The runtime engine is not known to be turning complete. It has no expressions and cannot loop, only forward jumps are permitted.
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.
I was given trauma from my decades of ELisp configuration for emacs...
Writing a parser for Lisp S-expressions is dead-simple, I wonder if that's why they used the format.
I went down the sandbox-exec rabbit hole recently trying to get a “safe shell” for poking at random GitHub projects. I eventually realized I was solving the wrong problem.
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.
> clone repos into ~/projects
Cloning them there means leaving access to your SSH keys, right?
You can tell MacOS was developed by OS nerds but stifled by product managers. There are a lot of gems like Sandboxing and Hyperkit with incredible features and practically no user interface.
Why is not spending resources to develop infrequently-used features that aren't revenue streams "stifling"? Granted, I too would love to have nice UIs for those out of the box, but > 99.9% of Mac users don't care, and 3rd-party developers can pick up the slack and maybe make some money filling the gap.
that's the short-term, MBA-style mindset to which I'm referring. Much of the popularity of MacOS came from the open source community filling that gap despite lacking support. So there is clearly demand that the PMs were not tapping into.
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.
> Sandbox profiles use a Scheme-like syntax (a LISP dialect) with parentheses grouping expressions.
Wow this is cool
Are sandbox-exec and seatbelt no longer deprecated? I genuinely don’t know. I am asking
Still deprecated. Still in use by everyone.
what is with the ai written articles lately? and ai designed websites?
who looks at it and goes "yes, ill upvote this. more people should see it."?
what is with people who are convinced everything is written by ai with no evidence lately?
This content was from a year ago and was not written by AI.
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.