It’s not very often that both halves of this blog converge on a single technical term, but they did last week in provenance.

Under this painting by Paul Cézanne is an account of each transfer of ownership, going right back to the dealer Ambroise Vollard, who sold it on to the artist Paul Vallotton, and so on, up to its most recent sale by Christie’s auction house in New York to the current owner, in 2004. With the right documentary evidence, it’s as good as a guarantee that it’s the original work by Cézanne.

Imagine my surprise when I was inspecting the extended attributes of a quarantined app in a virtual machine, to see the word provenance in an attribute that had been attached to the app after it had completed its first run. That led to a description of the new extended attribute, and further examination of logs.

I wasn’t the first to notice this extended attribute in Ventura: I found a few scattered mentions of it from earlier this year, but no one seemed to know where it had come from, nor where it was going to. There was one fascinating thread, helped as usual by Quinn “The Eskimo!”, in which the new com.apple.provenance extended attribute was conspicuously present, but subsequent discussion managed to avoid it altogether.

It took a little work with log extracts, and invaluable information from Randy and Pico here, to piece together what I know of Ventura’s new provenance tracking of apps. But what I’ve seen so far appears incomplete, and doesn’t yet seem to be used particularly effectively.

Given that the provenance extended attribute contains that app’s primary key in a provenance tracking table also containing the cdhash and other information about that app, and that Ventura effectively checks every app launch as if it was the first run of a quarantined app (although it does appear more tolerant of minor signature errors), it’s logical that provenance checking could be intended to reduce the impact. That would be feasible if app launch were perceptibly slower in Ventura, but it’s not something that has been reported by users. In any case, according to my log extracts, the provenance of an app isn’t currently accessed until after Gatekeeper checks have been completed.

I suspect that provenance tracking isn’t intended to reduce Gatekeeper checks, but to make them harder to cheat.

For conventional, static third-party apps not supplied through the App Store, what Gatekeeper does at present should be robust. Each time a new version of the app is installed, it comes with its quarantine flag set, new Info.plist and cdhashes, and fresh notarization ticket. What, though, of an app that is modified in place, most commonly through an update installed using Sparkle? Any old quarantine flag says that it has cleared its first run, but it hasn’t in its updated form, and some or maybe all of its cdhashes may have changed. Under the new rules it should have been correctly re-signed, but is clearly not the app that it was originally. It’s here that provenance tracking could have an important role that the old quarantine extended attribute can’t fulfil.

There are other changes happening in app security too. If you’re an avid reader of the log, you may have come across the very occasional entry mentioning Bastion and XProtectBehaviorService. Here’s a matching pair from a full first-run Gatekeeper check:
1.037060 syspolicyd Got bastion violation BastionRule-3 path /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder responsible path: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
1.080139 XProtectBehaviorService Processed behavioral violation for process file:///System/Library/CoreServices/Finder.app/Contents/MacOS/Finder file:///System/Library/CoreServices/Finder.app/Contents/MacOS/Finder BastionRule-3

And here’s a slight variation from another:
1.410297 syspolicyd Got bastion violation BastionRule-2 path /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder responsible path: /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder
1.529422 XProtectBehaviorService Processed behavioral violation for process file:///System/Library/CoreServices/Finder.app/Contents/MacOS/Finder file:///System/Library/CoreServices/Finder.app/Contents/MacOS/Finder BastionRule-2

The inference is that XProtect now not only checks Yara signatures, but also monitors app behaviours, and has at least three rules that it applies. Finder can perhaps be forgiven for its misbehaviour here, which appears related to its habit of asking LaunchServices to run apps. It has been some years since I first wondered whether macOS security was going to become based more on potentially malicious behaviour than static analysis. Hopefully this will become more extensive.

Maybe finding these new features in macOS isn’t a matter of providence at all, but more a matter of exploring the log more often and more thoroughly. Just like we used to.