Live data from Hacker News

macOS's Little-Known Command-Line Sandboxing Tool (2025)

igorstechnoclub.com

71–80 of 96 posts

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#71
post #50

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.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#73
post #46

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.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#74

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) a…

> clone repos into ~/projects

Cloning them there means leaving access to your SSH keys, right?

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#75
post #58

Earlier quoted context omitted.

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."

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#77
post #58

Earlier quoted context omitted.

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.

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.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#78
post #32
post #7

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.

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.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#79
post #46

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

"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.

Re: macOS's Little-Known Command-Line Sandboxing Tool (2025)

#80
post #33

Earlier quoted context omitted.

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.
Post reply on HN