Entitlements are settings baked into an app’s signature that enable it to do things that otherwise wouldn’t be allowed. Many let App Store apps do things their sandbox wouldn’t normally permit. Others give access to features that are controlled by privacy protection, so may be used by apps that aren’t sandboxed. A few enable apps specially approved by Apple to use features in macOS that aren’t generally available, such as working with APFS snapshots.

One way to run third-party apps in relative security is to confine them to a tightly restricted environment, a sandbox. That denies them the ability to access storage or other resources outside those dedicated to it in its sandbox. That’s too restrictive for the great majority of apps, which need to be able to open and save documents to folders such as ~/Documents, so entitlements specify which sandbox restrictions they’re allowed to break. In the case of opening and saving documents outside the sandbox, the entitlement is named com.apple.security.files.user-selected.read-write, and gives that app read and write access to files the user has selected in a standard macOS Open or Save dialog. Apple requires that all apps distributed through its App Store run in their own sandbox, so they all claim entitlements to be able to work beyond that.

Sandboxed apps all have their own entitlement to their sandbox, com.apple.security.app-sandbox, which isn’t used by apps that are notarized but not sandboxed. Whether sandboxed or not, an app might need access to the Mac’s camera, and for that it will need an entitlement named com.apple.security.device.camera.

Thus, entitlements fall into groups:

• Those that can be used by any app that wants access to controlled features, depending on whether it’s sandboxed or not.
• Those that give access to macOS features that have to be approved by Apple.
• Those that are private to Apple’s own apps and can’t be used by third-parties.

Viewing entitlements

The Finder and other macOS utilities don’t reveal whether an app runs in a sandbox, nor list its entitlements. For that you’ll need a third-party tool such as Mothers Ruin’s Apparency.

Apparency’s Entitlements pane lists all those baked into that app’s signature. My own free Taccy also lists entitlements, but for this purpose Apparency is the better tool by far.

Apps that aren’t sandboxed, only hardened and notarized, will only have entitlements if they need to access privacy-protected features, or use restricted features in macOS. In many cases, that means they will have neither entitlements nor a provisioning profile.

com.apple.security

These give an app access to files and features that are restricted, either by the sandbox, or by privacy protection.

Sandbox controls

These are options that extend an app’s abilities beyond the sandbox, starting with the entitlement that sets the sandbox in the first place. They aren’t used by apps provided outside the App Store that are only notarized and not sandboxed. Apple provides fuller details of the sandbox here.

Examples include:

• com.apple.security.app-sandbox runs the app in a sandbox, and is standard for all sandboxed apps
• com.apple.security.files.user-selected.read-write gives read and write access to files the user has selected in a standard macOS Open or Save dialog
• com.apple.security.files.bookmarks.app-scope gives access to security-scoped bookmarks with app scope
• com.apple.security.files.bookmarks.document-scope gives access to security-scoped bookmarks with document scope
• com.apple.security.network.client allows it to open outgoing network connections
• com.apple.security.print allows it to print.

Privacy controls

These give access to information, devices and features that are controlled by the privacy features in macOS, enforced either by Location Services or by TCC. These are used by any third-party app, whether supplied through the App Store or not, and include:

• com.apple.security.personal-information.addressbook gives access to the content of the address book
• com.apple.security.personal-information.location gives access to location data from Location Services
• com.apple.security.device.camera gives access to the camera
• com.apple.security.device.microphone gives access to the microphone
• com.apple.security.automation.apple-events enables automation using AppleEvents.

These normally have a corresponding list in Privacy & Security settings.

com.apple.developer

These entitlements can only be granted by Apple, and control access to macOS features that aren’t generally available. Among the most common are:

• com.apple.developer.endpoint-security.client enables it to monitor system events for potentially malicious activity using Endpoint Security
• com.apple.developer.persistent-content-capture is required for a Virtual Network Computing (VNC) app to have persistent access to screen capture
• com.apple.developer.driverkit gives an extension permission to run as a user-space driver
• com.apple.developer.vfs.snapshot gives access to snapshot features
• com.apple.vm.networking allows virtual network interfaces without their having to escalate privileges to the root user, typically in bridged networking.

com.apple.private

These are private to Apple’s own apps, and encompass many other com.apple entitlements that aren’t documented for third-party developers. Examples include:

• com.apple.private.applemediaservices
• com.apple.private.dmd.policy
• com.apple.private.octagon
• com.apple.authkit.client.private
• com.apple.duet.activityscheduler.allow.

Some appear self-explanatory, others are opaque.

Command tools and standalone executables

Although Mach-O binaries such as command tools and daemons can be hardened and signed, thus can be notarized, they can’t have a provisioning profile embedded, so can’t have entitlements. Apple recommends working around this by wrapping them in an app-like structure, as explained here.

Entitlements for access to features controlled by privacy protection rely instead on the attribution chain to determine whether they’re entitled. Thus a command tool called by an app isn’t expected to have the entitlement, but the app calling that binary is.

Stripping signatures

Because entitlements are baked into the signature, if you were to strip the signature from an app, that would remove all its entitlements. For a sandboxed app, that might not be fatal, but for most other types of entitlement, that could render the app non-functional. Resigning the app with an ad hoc signature wouldn’t help either.

References

Apple’s Entitlements documentation
Tech Note 3125 on provisioning profiles for code signatures
If you can’t find an entitlement in any 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.

Accessing files and folders isn’t as simple as it used to be. There was a time when, if a file was in your Home folder, you had full rights over it, and apart from those parts controlled by root, you had free roam. Now macOS plays evil tricks: you try to save a file in ~/Documents only to be told that you can’t, and even when you’ve assumed root privileges much remains out of your control. This article explains five barriers that you may have to negotiate.

Those are:

• Permissions were part of Mac OS X when it was introduced nearly 25 years ago, and provides basic controls over which users and groups can read or write items, in a system common to Unix and many other operating systems.
• Access Control Lists (ACLs) refine those permissions with more specific restrictions on access to items, and were introduced in Mac OS X 10.4 Tiger in 2005.
• Privacy controls enforced by the Transparency, Consent and Control (TCC) system have included restrictions on access to specific folders since macOS 10.14 Mojave in 2018.
• System Integrity Protection (SIP) was introduced in 2015 with El Capitan, and primarily puts system folders beyond the reach of root.
• App sandboxing is security protection that limits the files individual apps can access by imposing a sandbox as determined by their entitlements.

For any app including the Finder to have access to a file or folder, all five of those must give approval.

Permissions

The simplest and most basic controls, these can be inspected and changed in the Finder’s Get Info dialog for all accessible files and folders. They control the ability of apps and other code to read from and write to each file and folder. Normally, if you’re the named owner of a file or folder, you expect to have both read and write access, and that ensures that the apps you run with user privileges can open, edit and save changed files. There’s also the Locked checkbox that might seem obvious, although it often gets overlooked as a cause of problems when saving a file.

Some locations are particularly sensitive to errors in permissions, such as all those property lists containing settings for apps and services stored in ~/Library/Preferences. They are mostly handled by a background service cfprefsd, but if permissions have become changed so that it can’t access a property list it needs to use, all sorts of strange errors can result. In the past measures have been used to correct or repair those permissions, but those problems should now be long since past, and repairs are generally unnecessary and potentially dangerous.

ACLs

Access Control Lists, ACLs, add a more sophisticated system for enforcing more specific restrictions that cover a wide range of features. Their only common use in modern macOS is to preserve standard structures of folders in the Home folder. Regular Posix permissions don’t do that well, so a common ACL used is
group:everyone deny delete
to prevent anyone from deleting the folder it’s applied to. You should find that ACL on each named user folder and the Guest folder in /Users. Within each user folder, it’s normally applied to all the standard folders, including Desktop, Documents, Downloads, Library, Movies, Music, Pictures, Public and Sites, and on some folders within ~/Library.

The result of that ACL is that any attempt to remove that folder fails silently, so preserving the standard layout. But it doesn’t affect access given to the contents of those folders, nor can it be held responsible for errors when trying to read or write files within a protected folder. Unfortunately, the Finder’s Get Info dialog isn’t exactly forthcoming about the presence or effects of ACLs, merely stating that the user has “custom access”.

Thankfully, some GUI tools give good access to ACLs, and my favourite remains TinkerTool System, which has excellent support for them, and much more besides. It’s most valuable in displaying Effective Permissions.

Built-in tools are provided in Terminal. Show all ACLs using the command ls -le to return entries such as
drwx------@ 5 hoakley staff 160 8 Oct 12:09 Desktop
0: group:everyone deny delete
drwx------@ 81 hoakley staff 2592 17 Feb 15:42 Documents
0: group:everyone deny delete

You can add an ACL using chmod, such as
chmod +a "everyone deny delete" MyFolder

Privacy protection

macOS designates certain locations and resources as being private, and protects them using its Transparency, Consent and Control (TCC) system. Among the folders that this protects are the Desktop, Documents, Downloads, and removable storage. While access to individual folders has fine control, if you do encounter problems it’s usually simplest to add that app to the list of those with Full Disk Access, in Privacy & Security settings, in the first instance. That can leave a lot of apps with unnecessary access to private data, so you should periodically check through the list of apps with Full Disk Access to ensure they all still require it. Note that Full Disk Access can’t override permissions or ACLs.

In Sequoia, privacy-protected folders now include:

• ~/Desktop
• ~/Documents
• ~/Downloads
• iCloud Drive
• third-party cloud storage, if used
• removable volumes
• network volumes
• Time Machine backups.

SIP and security

In principle, System Integrity Protection (SIP) should only apply to system files, but it’s also used to lock down some other components, including com.apple.macl extended attributes, which can be attached to user files. Those have been implicated in some problems in which regular user documents become locked down, and typically won’t save any changes. Although the exact role and use of this extended attribute isn’t clear, it’s generally accepted as designating an app that’s approved to edit that file, so providing document-specific privacy control.

SIP is easy to spot in the Finder’s Get Info dialog, as only the System has write access, and permissions are again described as “custom access”.

com.apple.macl extended attributes are normally protected by the same mechanism that applies SIP, so any attempt to remove them is likely to fail. One workaround for that is to pass the file through another volume, so that when it’s copied back the extended attribute is no longer protected, and can be stripped.

These problems appear most likely when apps other than that set as the default app to open a document type are used to edit files. Another approach to their solution is to select an affected document in the Finder, Get Info, set it to Open with the default app, then click on Change All… to reset all others to that default app.

Sandboxes

Sandboxing is a security feature that individual apps can opt into. As it’s a requirement of those distributed through Apple’s App Store, it’s now common in third-party software. The starting point is to restrict a sandboxed app to the folders created in its sandbox, saved in its folder in ~/Containers. As this severely limits the usefulness of most apps, it’s common for them to have entitlements that extend their ability to access files and folders beyond that basic sandbox.

As this is controlled by the entitlements system and baked into the app’s signature, it’s not something that the user has any control over. If a sandboxed app is unable to access files or folders that you need to use, contact its developer.

What can you change?

• Permissions are generally simple and easy to control. Beware of changing those in Library folders, but your documents and other files should be straightforward to manage.
• ACLs are more obscure and complex. Unless you understand what you’re doing, leave them well alone.
• Privacy controls are extensive and fraught. The only control you have here is giving apps Full Disk Access when needed. Check that list periodically to ensure you haven’t been overgenerous.
• SIP shouldn’t be tampered with unless you fully understand what you’re doing. On Apple silicon Macs disabling it reduces boot security to Permissive, with other consequences. Details of fine control using csrutil are here.
• App sandboxing isn’t within user control.