App Store apps run in a sandbox which severely limits what they can do. If there were no options beyond that, they’d all be pretty useless. Baked into their signatures are entitlements, from which macOS allows them capabilities which enable them to be more useful to us.

One widespread example is the com.apple.security.files.user-selected.read-write entitlement, which you should see is set to ‘true’ (or 1) in pretty well all App Store apps. This allows the app to read and write to files selected by the user in the standard Open and Save File dialogs. Without it, the app would hardly be able to do anything.

Originally, before the introduction of the sandbox, there were no entitlements. Apps were free to do whatever they wanted within the normal Unix limits of permissions, and access provided to macOS features. The idea of the sandbox is to limit the damage that an app can do, were it defective or malicious, and to keep important and private data from prying eyes.

Now, in Mojave, there are two separate but related systems, the app sandbox and hardening, and additional limits imposed by privacy protection. It’s all getting rather confusing. I hope that this article will clarify your understanding of entitlements, and the different options now and in the future.

As entitlements are baked into an app’s signature, they’re beyond user control. If an app has an entitlement to access iCloud data or to print, you can’t unentitle that app, although you can, for instance, use a firewall to stop an app from phoning home, if you wish. The exceptions to this are resources which are protected by Mojave’s new privacy protection system, where you can refuse the app access despite its entitlement.

Many entitlements have fairly obvious meaning, but there isn’t a complete official listing of all those in use. Apple’s original reference to entitlement keys was last updated two years ago, in March 2017, and is now woefully out of date, and doesn’t of course cover those for hardened apps.

Incomplete but more recent lists are provided by Apple for sandboxed apps, and for those which are hardened and notarized. If you can’t find an entitlement in either of those lists, try looking in Jonathan Levin’s database of all known entitlements for iOS and macOS, which is as comprehensive as we’re likely to get.

Hardened apps have far fewer entitlements because the restrictions imposed on them are not as restrictive as those of the sandbox. They fall into two groups: app behaviours which could be exploited by a malicious app, such as loading frameworks signed by other developers, and resources which are protected by Mojave’s new privacy protection system, TCC.

The latter don’t cover all the options available in the Privacy tab of the Security & Privacy pane: hardened apps can’t claim an entitlement to Full Disk Access, nor to Accessibility, which are still controlled by the user. That same tab also gives you control of what a hardened app has your consent to access, but as with sandboxed apps, you can’t alter the app’s entitlements.

There are several ways of discovering an app’s entitlements. If you’d prefer to do this in Terminal, the command
codesign --display --entitlements :- appname.app
returns a formatted property list containing all entitlements, for example
Executable=/Applications/xattred.app/Contents/MacOS/xattred
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.personal-information.addressbook</key>
<true/>
<key>com.apple.security.personal-information.calendars</key>
<true/>
<key>com.apple.security.personal-information.photos-library</key>
<true>
</dict>
</plist>

My free app Taccy lists entitlements in its lower text view:
Entitlements:
com.apple.security.personal-information.photos-library : 1
com.apple.security.personal-information.calendars : 1
com.apple.security.personal-information.addressbook : 1
This is useful as it also displays information from the app’s Info.plist showing a list of TCC’s protected resources for which the app has the required information strings.

Perhaps the most comprehensive information is delivered by Max Inspect (from the App Store), which is highly recommended for developers and administrators.

The third class of apps, those which are neither supplied through the App Store nor hardened and notarized, don’t of course have the same need for entitlements.

But sometime in the not too distant future, perhaps this coming autumn/fall with macOS 10.15, Apple intends that the only apps allowed through the quarantine process are those which are notarized. That won’t prevent you from using your existing non-notarized apps, nor from local copies of apps which aren’t notarized or from the App Store, but it means that all apps which you download from the Internet will use the entitlements system.