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

Even that’s too restrictive for the vast majority of apps. You expect an image editor to be able to open and save images in folders you control, such as ~/Documents, 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 to ease some 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.

This overlaps with privacy protection 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 desire 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 overlapping with those to protect privacy.

What started off as an app running entirely within its sandbox is gradually being allowed to do more, and that sandbox is becoming less effective as the app gains access to more outside resources. Although this might appear increasingly pointless, balanced compromises can be reached that limit an app’s attack surface without frustrating users.

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

macOS also applies sandbox features to apps that aren’t marked to be run in a sandbox, most notably to implement privacy protection. By default, when any app tries to list the contents of a protected folder, the sandbox blocks that unless the privacy controller TCC authorises access. Unfortunately that can lead to complex interactions between sandboxing and TCC.

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, a curious omission. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency. 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. You would 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 requiring them.

Another distinctive feature of a sandboxed app is its named container folder, in ~/Library/Containers, where its sandboxed storage is located. An app’s container is created automatically by macOS when that app is run for the first time, but isn’t cleaned up when the app is removed, so can become orphaned and merit careful manual removal.

As 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. A few 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.