For a computer to be really secure, it shouldn’t run any untrusted code. In macOS that would mean no third-party apps, which would severely limit the appeal of a Mac. One way round this is to run untrusted code in a tightly restricted environment, denying it the ability to access storage, memory or other resources outside those dedicated to it by its sandbox, managed by macOS.

Even that’s too restrictive for the great majority of apps, though. You expect an image editor to be able to open and save images in folders you control, like ~/Documents, or those in your Pictures folder or Photos Library. So, having put an app into its sandbox, the next thing you need to do is provide it ways out of those restrictions. In Apple’s operating systems, those are granted according to entitlements burned into the app’s signature.

Considering our hypothetical sandboxed image editor, those entitlements are likely to include com.apple.security.files.user-selected.read-write, giving the app read and write access to files the user has selected in a standard macOS Open or Save dialog.

There is some overlap here with privacy protection, as controlled by TCC. The standard user folder for images is ~/Pictures, so to gain read and write access to that the app needs an entitlement for com.apple.security.assets.pictures.read-write as well. Then there’s the need to gain direct access to any built-in or external camera to capture movies and still images, requiring com.apple.security.device.camera, another entitlement that overlaps with those for privacy protection.

What started off as an app running entirely within the app sandbox is gradually being allowed to do more, and its sandbox is becoming less effective as the app gains access to more outside resources.

Apple requires that all apps distributed through its App Store run in their app sandbox, something marked in the app by another entitlement com.apple.security.app-sandbox, and explained here.

The Finder and other bundled utilities in macOS don’t reveal the entitlements claimed by sandboxed apps, indeed they don’t even tell you whether an app runs in a sandbox in the first place. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency, or my own free Taccy. Some sandboxed apps have such long lists of entitlements that they seem allowed to do almost anything, and you might wonder how effective that sandbox would be at preventing malicious behaviour from affecting your Mac.

Entitlements aren’t necessarily an indicator that an app is sandboxed, either: com.apple.security.app-sandbox is the tell-tale sign. Apple also uses entitlements to grant access to certain restricted features in macOS, like snapshots. Look at the entitlements of apps like Carbon Copy Cloner that have access to snapshots and you’ll see com.apple.developer.vfs.snapshot there for that purpose, even though that app isn’t sandboxed.

Because entitlements, including that to sandbox the app, are burned into an app’s signature, the only way to remove any of them is to strip the app’s signature altogether, and remove the whole lot. These days, you’ll then have to re-sign the app using an ad hoc signature, and you’re pretty well guaranteed that your doctored app won’t run at all. So there’s no practical way out of sandboxing and entitlements for those apps that require them.

Because App Store apps have to be sandboxed, but notarized apps supplied outside the App Store don’t, it might be tempting to see them as alternatives, or complementary to one another, but they’re very different. Some apps like BBEdit are both sandboxed and notarized, but that’s usually even harder than it sounds, and quite an accomplishment when it works well. But the restrictions of the sandbox make it impossible for many apps to do their jobs, so there will always be a need for those that don’t run in a sandbox.