There was a time that, once an app had come out of quarantine, its integrity and code signature might never be checked again, just taken on trust. This enabled apps to update themselves without worrying whether they were still correctly signed. It also enabled them to turn malicious, either by intent or as the result of changes made by other software.

So Apple has put a stop to this in macOS Ventura. But doesn’t that impose overhead every time that you launch an app, and what about repeated execution of command tools? This article explores how macOS 13.4.1 copes.

First run in quarantine

When you first run an app that you’ve just downloaded to your Mac from a source that results in it being put into quarantine, the following has occurred:

• The app is translocated and run from a distant and unpredictable path.
• The app’s signing certificate is checked, to ensure its validity, and its chain of trust to Apple’s root certificate. If it’s not signed by Apple or a Developer ID Application certificate, then an ad hoc certificate is expected on Apple silicon systems.
• The app’s integrity is checked against its secure hashes (cdhashes) to ensure that protected parts of the app haven’t been altered since signing.
• The app is scanned for malware signatures, according to the current list provided by XProtect.
• Notarization is checked, preferably online with Apple using CloudKit, or when that’s unavailable in a ticket stapled to the app.
• App sandbox, entitlements and hardening are also checked, as they determine the runtime environment to be provided.

In recent versions of Ventura, the app also has a provenance extended attribute added, and that links to its entry in the new provenance database.

Some or all of those can also be triggered when a known app, which has already passed its first run tests, is run from a previously unknown path, when it’s put back into quarantine, or when it remains stuck in app translocation.

If the app isn’t notarized, then it will normally be refused at the first attempt to launch it, and the user has to bypass the notarization warning by opening it in Finder a second time. Provided that’s completed, Ventura will still run code that is correctly signed but not notarized, and even apps that aren’t signed using an Apple developer certificate but using an ad hoc certificate. Rumours that these bypasses have been removed are incorrect: even on Apple silicon Macs, you can still run apps and command tools that haven’t been notarized, provided that they have been signed, at least ad hoc.

First run without quarantine

App translocation may occur at random, but wasn’t observed in these tests using apps and command tools that had no quarantine extended attribute attached to them.

Although checking of signing certificate and the app’s integrity are performed, successful results aren’t detailed in the log any more. However, an ad hoc signed app will result in log entries like
0.953135 AppleMobileFileIntegrity No certificate chain found
0.953136 AppleMobileFileIntegrity Failure getting cert chain
0.953177 AppleMobileFileIntegrity Basic requirement validation failed, error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)" UserInfo={SecCSArchitecture=arm64}
0.953273 amfid /Applications/DelightEd3resigned.app/Contents/MacOS/DelightEd not valid: Error Domain=AppleMobileFileIntegrityError Code=-423 "The file is adhoc signed or signed by an unknown certificate chain" UserInfo={NSURL=file:///Applications/DelightEd3resigned.app/Contents/MacOS/DelightEd, NSLocalizedDescription=The file is adhoc signed or signed by an unknown certificate chain}
0.953322 AppleMobileFileIntegrity AMFI: code signature validation failed.

Gatekeeper then assesses the process and an XProtect scan is performed for malware signatures, and what is presumably the cdhash of the app or command tool is then looked up in Apple’s CloudKit database to see if it’s recognised there.

In the case of code signed using an Apple developer certificate, this explicitly checks whether the code has been notarized under a legacy scheme, in which case it may not have its notarization ticket stapled to the app. If there’s no notarization ticket available from the CloudKit lookup, a Security MacOS error of 3 is reported in the log.

On successful completion of the Gatekeeper scan, provenance data is obtained for the app or command tool, added to the provenance database, and a com.apple.provenance extended attribute is added to the app or command tool:
1.216364 syspolicyd Found provenance data on target: TA(917fa0aed8a1a838, 0), PST: (path: /Applications/DelightEd3.app), (team: QWY4LRW926), (id: co.eclecticlight.DelightEd3), (bundle_id: co.eclecticlight.DelightEd3)
1.216456 syspolicyd Created provenance data for target: TA(917fa0aed8a1a838, 0), PST: (path: /Applications/DelightEd3.app), (team: QWY4LRW926), (id: co.eclecticlight.DelightEd3), (bundle_id: co.eclecticlight.DelightEd3)
1.216462 syspolicyd Putting executable into provenance with metadata: TA(917fa0aed8a1a838, 0)
1.216464 syspolicyd Putting process into provenance tracking with metadata: 1489, TA(917fa0aed8a1a838, 0)
1.216466 syspolicyd Tracking process with attributes: 1489, TA(917fa0aed8a1a838, 0)

Subsequent runs

When the app or command tool is run a second or subsequent time, the log reports when provenance data has been found, and can be used to track the process:
0.710961 syspolicyd Tracking process with attributes: 1510, TA(917fa0aed8a1a838, 0)
When that’s successful, no further entries appear recording Gatekeeper checks, XProtect scans, signing or certificate checks, or CloudKit checks for notarization: provenance tracking now seems able to replace them all. Evidence from testing modified apps and adding quarantine flags implies that the cdhash(es) in provenance data are validated before they can be used.

Command tool loops

One situation where repeated security checks could have significant impact is when repeatedly executing a third-party command tool in a script. To assess this, I ran a script loop of the form
for i in {1..10}; do; blowhole; done
calling my own notarized tool that writes a simple message to the log.

At the start of the script, the command tool was checked once and tracked using provenance
0.539929 syspolicyd Tracking process with attributes: 1428, TA(917fa0aed8a1a838, 0)
This wasn’t repeated during the loop. The command was executed ten times in 0.037 seconds, taking 0.004 seconds per call. Provenance tracking thus appears to overcome overhead without compromising security.

Conclusions

Recent versions of Ventura have introduced what appears to be an effective mechanism of ensuring high levels of code security without incurring significant overhead, using provenance tracking. This does assume that integrity is checked against previous cdhashes, although that isn’t explicitly recorded in the log.

Although apps and other executable code that haven’t been notarized don’t benefit from Apple’s malware checks, current Gatekeeper checks coupled with provenance tracking appear to provide good assurance to those still having to use code that hasn’t been notarized, or even signed with an Apple developer certificate.

Thanks to Jeff Johnson for pointing out that notarization checks are preferably performed online, with the local ticket as a fallback when that’s not available.