What is an entitlement on macOS, and how do the App Sandbox and the Hardened Runtime use entitlements differently?

## Signed claims, not configuration An entitlement is a key/value pair in a property list that is embedded **inside the code signature**. That placement is the whole point. A configuration file can be edited by whoever has write access; entitlements cannot, because changing them changes the signed bytes and breaks the seal, at which point Gatekeeper and the kernel stop trusting the binary at all. Entitlements are therefore statements the developer made at build time, attested by their signing identity, and the system can rely on them at runtime. You can read them out of any signed binary: ```sh codesign -d --entitlements - /Applications/Example.app ``` Some entitlements are freely usable by any developer; others are *restricted* and only take effect when the signing certificate is authorised by Apple to carry them. That two-tier design is why an app cannot simply claim a powerful capability for itself. ## App Sandbox: deny by default, widen deliberately Adding `com.apple.security.app-sandbox` opts the application into confinement. Once inside: - The app gets a **container** — a private directory under `~/Library/Containers/<bundle-id>/Data` — and its view of `$HOME` is redirected there. Code that writes to `~/Library/Preferences` lands inside the container, invisible to the rest of the system. - Network access, file access outside the container, camera, printing, and hardware access are all denied. - Each capability must be requested individually: `com.apple.security.network.client` for outgoing connections, `com.apple.security.network.server` for listening, `com.apple.security.files.user-selected.read-write` for files the user picks. That last one deserves a note, because it is the mechanism people find surprising. A sandboxed app cannot open `/Users/me/report.pdf` by path. But when the user chooses that file in an open panel, the system — through a separate, out-of-process file-picking service often called the powerbox — hands the app an extension to its sandbox for that file. The user's act of choosing *is* the authorisation, and the app never needed a broad grant. Security-scoped bookmarks let the app persist that access across launches. The sandbox is mandatory for App Store distribution and optional outside it. ## Hardened Runtime: protect by default, relax deliberately The Hardened Runtime is a signing option (`codesign -o runtime`) that turns on a set of process-level protections: - **Library validation** — the process may only load libraries signed by the same team identifier or by Apple, which stops an attacker dropping a malicious dylib beside the binary. - No unsigned executable memory, so a bug that gets bytes into a page cannot simply run them. - Restrictions on debugger attachment and code injection into the process by other software. Each of these has an escape entitlement for legitimate cases: `com.apple.security.cs.allow-jit` for a language runtime that compiles code at execution time, `com.apple.security.cs.disable-library-validation` for a host that loads third-party plug-ins signed by other vendors, `com.apple.security.cs.allow-dyld-environment-variables` for tooling that depends on dynamic-linker variables. Notarization requires the Hardened Runtime, and Apple's automated checks look at which relaxations you claimed. Turning off library validation on an application that has no plug-in model is a red flag in a review — and a real weakening, because it re-opens exactly the dylib-substitution attack the setting exists to close. ## The two are orthogonal A common muddle is to treat sandbox and hardened runtime as the same switch. They are not: | | App Sandbox | Hardened Runtime | |---|---|---| | Default posture | deny nearly everything | apply a fixed protection set | | Entitlements | grant capabilities | remove protections | | Required for | App Store | notarization | | Protects | the system from the app | the app from injected code | An app can be both sandboxed and hardened, either, or neither. And neither one replaces the privacy consent layer: the user's approval for camera, microphone or their Documents folder is a separate runtime gate that applies to sandboxed and unsandboxed apps alike. ## What this means in practice When you are asked to make a macOS build "work", resist the reflex to add entitlements until it stops complaining. Every entitlement you add is a permanent, signed statement about what your program may do, visible to anyone who inspects the binary and to Apple's notary service. Claim the narrowest set that supports the feature, and be able to justify each one — that justification is precisely what an interviewer is probing for.