In the first article, I looked at the requirements and features of notarization. Among those is the need for a hardened runtime, which I started to examine in the second article, where I pointed out the opt-outs which notarized apps can take, and how you can examine them. In this third and final article, I look at the other half of the hardened runtime, which concerns privacy protection.

When a developer configures the hardened runtime options in Xcode, the upper half of the settings determine which, if any, opt-outs they choose for the hardened environment. The lower half contains flags to determine which protected private data the app will be entitled to access.

When a notarized app tries to access Audio Input, for example, its request is checked by TCC, the Transparency Consent and Control subsystem. If the app has that entitlement, it should provide an informative string to be displayed in the dialog to be presented to the user, explaining why the app wants that access.

Notarized apps which try to access protected resources without the appropriate entitlement and an accompanying informative string will, at best, simply be refused. At worst, the app will be crashed, on the basis that the access could be malicious.

Entitlements include:

• com.apple.security.device.audio-input (previously com.apple.security.device.microphone), which allows recording using the built-in microphone and other Core Audio input;
• com.apple.security.device.camera, which allows capture of still and video images from any built-in camera;
• com.apple.security.personal-information.location, which gives access to location information from Location Services;
• com.apple.security.personal-information.addressbook, which gives read and write access to the Contacts address book;
• com.apple.security.personal-information.calendars, which gives read and write access to the user’s calendars;
• com.apple.security.personal-information.photos-library, which gives read and write access to the user’s Photos library;
• com.apple.security.automation.apple-events, which allows the app to post AppleEvents to other apps.

com.apple.security.personal-information.reminders has also been used earlier for reminders.

Unlike opt-outs to the hardened runtime itself, the user should be made aware of the app seeking access to any of these using its entitlement, as it should result in a dialog requesting the user’s consent, and only with that consent will the app be added to the appropriate list in the Privacy tab of the Security & Privacy pane.

There’s another class of privacy entitlements, though, which are handled differently by TCC, and are normally grouped together under the entitlement of com.apple.private.tcc.allow. These private access entitlements include kTCCServiceAddressBook, kTCCServiceCalendar, kTCCServicePhotos, kTCCServiceReminders, kTCCServiceCamera, kTCCServiceLiverpool (location), kTCCServiceMicrophone, kTCCServiceSystemPolicyDownloadsFolder, kTCCServiceListenEvent, and kTCCServiceScreenCapture, whose purposes are obvious from their names. You should only encounter these in Apple’s own apps such as Safari. As they’re not associated with conventional user consent dialogs, they aren’t normally apparent to the user unless they happen to check an app’s entitlements. Accordingly, they’re not accompanied by any informative string either.

As with the rest of the hardened runtime, privacy access entitlements require SIP to be enabled for them to work; disable SIP and the hardened runtime with its extensive controls is also disabled, as established by Jeff Johnson over two years ago.

The only method provided by macOS to check privacy-related entitlements is with
codesign --display --entitlements :- appPath
as for those controlling opt-outs to the hardened runtime. My free utility Taccy not only provides that list for you, but also shows public and private entitlements of greatest interest, together with their informative strings.

In summary, then, a recently notarized app is required to meet several criteria on code signing, and to adopt a hardened runtime. But apps which have been notarized under older legacy rules may be exempt. The only common requirement is that the app has been checked by Apple for malicious content, but several malicious apps have managed to pass that check.

The full hardened runtime does provide good assurance that the app as checked by Apple can’t turn malicious, neither can malicious software abuse it. But most of the requirements for the hardened runtime are subject to opt-outs, which the user is normally unaware of.

The hardened runtime also prevents the app from accessing protected private data or services without having appropriate entitlements and informative strings. Although the user has to give their consent before the app is given access to these, there’s also a large set of private entitlements of which the user isn’t made aware.

Whatever you think of the value of notarization, it has so many opt-outs and exceptions that it’s hard to know whether any notarized app is really ‘safe’.