Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

igorstechnoclub.com

Post reply on HN
Print view View original

81–90 of 96 posts

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

#81

Post by VogonPoetry »

selridge wrote: post #39
TingPing wrote: post #34

Earlier quoted context omitted.

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.

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.

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

#82

Post by selridge »

VogonPoetry wrote: post #81
selridge wrote: post #39

Earlier quoted context omitted.

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 bas…

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.

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

#83

Post by johnmw »

jpeeler wrote: post #51
cjbarber wrote: post #28

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)

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…

Also (in case people haven't already seen this), I recently discovered Docker now has an easy way to run agents in a sandbox, ie:

  docker sandbox run claude ~/project-a
https://docs.docker.com/ai/sandboxes/

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

#84

Post by egorfine »

extra88 wrote: post #77
egorfine wrote: post #62

Earlier quoted context omitted.

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.

crontab exits immediately on one of the macs. The other had crontabs prior to upgrading to 15.something.

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

#85

Post by VogonPoetry »

selridge wrote: post #82
VogonPoetry wrote: post #81

Earlier quoted context omitted.

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 bas…

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.

Does this mean you tried to ship an App in the Apple App Store but could not because of some restriction?

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

#86

Post by egorfine »

derefr wrote: post #75
egorfine wrote: post #62

Earlier quoted context omitted.

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

The one machine where cron was working, had crontabs prior to upgrade to 15.x. The other had none.

I have googled back then and discovered that yes Apple specifically want us to suffer with their braindamaged launchd instead of cron, and thus they went to extraordinary lengths to get rid of working tools.

Anyway, cron is easy to rebuild from sources, so that's what I did.

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

#87

Post by VogonPoetry »

simonw wrote: 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

I am not sure using sandbox-exec is a good security architecture for AI agents. It sure is convenient and available to everyone right now. I've made another comment elsewhere in this discussion about what I think "deprecated" means - it is a sharp tool that could break if not tracking everything that changes, including every change in a SW update. It is also easy to get wrong if there is not a "(default deny)" in the profile. An agent could escape if they can find a mach service or some other system call coordinated proxy service. Java, Silverlight and Flash had backdoor communication mechanisms with other instances of themselves that could be abused.

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

#89

Post by selridge »

VogonPoetry wrote: post #85
selridge wrote: post #82

Earlier quoted context omitted.

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.

Does this mean you tried to ship an App in the Apple App Store but could not because of some restriction?

Why would it mean that?

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

#90

Post by davidcann »

Tiberium wrote: post #18
davidcann wrote: post #4

I made a UI for this to run terminal apps, like claude and codex: https://multitui.com

Codex already uses sandbox-exec on macOS :)

Yeah, they all do sometimes, but the agent decides what to allow and they can choose to not use it. This gives the user full control of the sandbox and you can run the agent in yolo mode.
Post reply on HN