How does macOS’s sandboxing mechanism protect applications?

24 Tem 21:49

macOS sandboxing is basically a set of ACL‑style rules that the kernel checks every time your code touches a protected resource. When you sign an app, Xcode (or codesign) adds an “entitlement” blob to the code signature – things like `com.apple.security.network.client` for outbound sockets or `com.apple.security.files.user-selected.read-write` for user‑picked files. The kernel’s sandbox daemon (`sandboxd`) reads those entitlements and builds a per‑process profile; it then uses the TrustedBSD MAC framework to gate every syscalls such as `open`, `connect`, `kextload`, etc. If the profile doesn’t have the matching rule, the syscall is denied and you’ll see a “Operation not permitted” error in the console. On top of that, each sandboxed app gets its own container directory under `~/Library/Containers/<bundle‑id>`. The container is a restricted view of the filesystem – the app can freely read/write inside its own container, but any path outside it is filtered by the sandbox rules unless you’ve explicitly requested the broader entitlement (e.g., `com.apple.security.files.downloads.read-write`). Kernel extensions are a special case: even if an app has the appropriate entitlement, the system will only load a kext that’s signed by Apple or an approved developer and that’s registered in the system’s extension whitelist. In practice, when you’re debugging a sandboxed app, I’ve found it handy to start with the minimal entitlement set, run the app, and then inspect the logs (`log show --predicate 'process == "<app-name>"'`) for denied operations – that tells you exactly which entitlement you need to add or which container path you should expose via a file‑open dialog. This iterative “add‑what‑you‑need” approach keeps the sandbox tight while still giving your app the capabilities it truly requires.