How does Ventura check an app’s security?

A couple of days ago I explained that Ventura checks apps more thoroughly than before. This article shows how it does that, according to what it records in the log.

Security checks made when an app is launched still depend on several factors. A set quarantine flag results in full first-run checks including app translocation and is atypical. To see a more representative process, I’ve looked at notarized apps being run for the first time without quarantine. As these apps had never been run in that VM before, security systems had no prior knowledge of them, and couldn’t make use of existing entries in the security database or cached information.

This account gives brief extracts from many thousands of log entries. In particular, the two remote connections involve long exchanges that are recorded across hundreds of transactions. Privacy protection was removed from the log for this purpose, and full network diagnostics were enabled. If you try to follow this along on another Mac, you may therefore not see the same amount of detail.

LaunchServices

In this case, running my app Cormorant from the main Applications folder, the action to open the app was recorded at almost exactly 1.009 seconds elapsed. First announcement was made by LaunchServices
1.016423 LaunchServices LAUNCH: Opening file:///Applications/Cormorant.app/ with 0 items on behalf of 377 role=e flags=8000001 (null)
where process 377 is the Finder.

Entries then report that the app bundle needs to be set as trusted so it can be launched, and LaunchServices looks for any plugins and extensions. A bundle record is then built for the app in the LaunchServices database by parsing its Info.plist, and once that’s complete the app is registered there as being trusted. LaunchServices then hands over launching the app to RunningBoard, which manages it and the resources available to it.

AMFI

As that’s going ahead, Apple Mobile File Integrity (AMFI) initiates security checks
1.051891 amfid Entering OSX path for /Applications/Cormorant.app/Contents/MacOS/Cormorant
and calls Security to perform a trust evaluation if necessary, then stated as
Requested evaluation with only soft restricted entitlements, but no soft restricted entitlements found

Gatekeeper

syspolicyd then initiates the Gatekeeper (GK) assessment
1.064942 syspolicyd GK process assessment: /Applications/Cormorant.app/Contents/MacOS/Cormorant >-- (/sbin/launchd, /Applications/Cormorant.app/Contents/MacOS/Cormorant) 1.064988 syspolicyd Gatekeeper assessment rooted at: /Applications/Cormorant.app
and starts with a scan of the app bundles for code
1.065387 syspolicyd starting work for scan for code: PST: (path: /Applications/Cormorant.app), (team: (null)), (id: (null)), (bundle_id: (null))

XProtect

The first step in that is to add a default exception for the team of the code-signing certificate, following which the app bundle is registered for protection, Gatekeeper scans the app bundle, and XProtect is called to perform a direct malware and dylib scan
1.068594 Xprotect is performing a direct malware and dylib scan: /Applications/Cormorant.app
This is one of very few explicit mentions of XProtect and its service in the log.

Note that this XProtect isn’t the background scanner XProtect Remediator, but the longer-established service that performs on-demand scans to detect malware using compiled Yara signatures. In Ventura, those scans occur whenever an app or executable code is to be run, although in earlier macOS they were only performed in app first-run when a quarantine flag was set.

Notarization

Next the notarization ticket is checked. As this is here stapled to the app bundle, it can be looked up directly with Apple’s service via iCloud at https: //api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup. This is performed through CFNetwork with TLS
1.078226 cloudkit record fetch: https: //api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, 2/2/f382b9b4ade8395e9c08e541d8bcd969a8d4c63e 1.078244 cloudkit request cache info: PFT-com.apple.gk.ticket-delivery-production-2/2/f382b9b4ade8395e9c08e541d8bcd969a8d4c63e, max-age=300

This is thought to involve checking of cryptographic hashes to verify the notarization and the integrity of the app bundle. Note that this is being run in a VM which has no Apple ID and no iCloud sign-in, and is an example of an iCloud service that is used by all Macs regardless of whether they’re signed into iCloud.

Apple declares api.apple-cloudkit.com with TCP on port 443 as one of its required network services, for notarization checks.

As that’s completing, XProtect results come in and are recorded by syspolicyd.

OCSP

The second remote connection made from within Gatekeeper’s processes checks the code signing certificate with Apple’s OCSP service. This is now performed with TLS:
1.246623 Network [C2 9700F665-9EB7-411B-B539-3B9DB847CC23 ocsp2.apple.com:443 quic-connection, url hash: 58998593, definite, attribution: developer, context: com.apple.CFNetwork.NSURLSession.{56391B2B-1A5B-451E-B726-A38553FA22CD}{(null)}{Y}{2} (private), proc: AFEBD0C4-9C35-30CE-9D1F-861ECE4EB6B7, effective proc: 2E7AA7E7-714F-319B-81B4-0EB2CA5E0930, pid: 208, uid: 0, account id: com.apple.trustd.TrustURLSession] start 1.247014 mDNSResponder [R175] getaddrinfo start -- flags: 0xC000D000, ifindex: 0, protocols: 0, hostname: ocsp2.apple.com, options: 0x8 {use-failover}, client pid: 182 (trustd), delegator pid: 208 (syspolicyd)

This has been the most controversial phase of Gatekeeper checks since it was discovered in 2020 that those checks were being made using plain HTTP rather than HTTPS. At the time, Apple made an undertaking that it would improve the reliability of its OCSP servers, would adopt a secure means of communicating with them, and would provide users with an option allowing them to turn off these checks altogether. That promise remains visible today, at the end of this article, but Apple still hasn’t fulfilled the last of those promises.

Apple declares ocsp2.apple.com with TCP on port 443 as one of its required network services, for certificate checks.

Gatekeeper complete

With that check complete, syspolicyd declares the Gatekeeper scan complete
1.352375 syspolicyd GK scan complete: PST: (path: /Applications/Cormorant.app), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
which is then confirmed with the kernel
1.367333 kernel AppleSystemPolicy evaluation result: 3, allowed, cache, 1678266601

Finally, nearly half a second after the user first started its launch process, Cormorant gets under way, loading its preference settings
1.476026 Cormorant CoreFoundation Loading Preferences From User CFPrefsD
then running its code.

Variations

Although Ventura still completes Gatekeeper checks on every app launch now, once an app has been entered into the LaunchServices and security databases, some of the tasks completed here can be omitted for subsequent runs. Certificate validations using OCSP are cached locally, reducing the frequency of online checks. However, as tests demonstrate, checks for malware using XProtect and for code integrity are now universal.

10Comments

Add yours

1

Old Coot on March 9, 2023 at 11:44 am

Just a dumb question. How does this all work without an internet connection if you run a frshly installed app and can not connect to a Apple server for Notarization?

LikeLiked by 1 person
- 2
  
  hoakley on March 9, 2023 at 11:51 am
  
  In that case, once connections have been attempted and failed, those should be abandoned and approval proceed. That’s simple for the notarization ticket, which can always be checked later. For certificate revocation, if the information isn’t available, the certificate must be assumed to remain valid.
  Experience shows that problems come not when there’s no internet connection, or Apple’s service is down, but when the server responds but then fails to complete the request. That can leave an app icon bouncing in the Dock for a long time, and sometimes can result in denial. Apple is supposed to have addressed this in its servers now.
  Howard.
  
  LikeLike
  - 3
    
    Alexandr on March 9, 2023 at 1:30 pm
    
    So can we complitly disable this onling check?
    As you wrote when the is a networ connection (anu evel local) but MacOS cannot reach the servers apps launch extremly clow and all MacOS stall on most basic tasks.
    As time pass with every new version Apple made using MacOS without internet connection practically impossible. And privacy matter is a very important, because now evely applaunched on Mac is known to Apple.
    Thank you.
    
    LikeLiked by 1 person
    - 4
      
      hoakley on March 9, 2023 at 2:00 pm
      
      You can’t have good privacy without good security.
      If you block outgoing connections to check notarization tickets and certificate validation, then you can’t trust your apps. What if Apple has revoked a code-signing certificate of malware, as it does? If you stop your Mac from checking the status of those certificates, then that malware will be able to continue running on your Mac.
      Frankly, if you don’t trust Apple, then don’t use a Mac. It’s as simple as that.
      And I didn’t write that, when the servers are unreachable, there’s a problem: if connection is attempted but fails, then it should be abandoned. And none of this make macOS stall either. Yes, if there are problems with a server it can slow or even block app launch, but doesn’t affect macOS.
      Howard.
      
      LikeLike
  - 5
    
    Rick on March 9, 2023 at 6:25 pm
    
    I guess that explains why occasionally an app that I’ve run before many times refuses to launch, saying “ cannot be opened”. Whilst I applaud Apple for implementing this level of security, it really should be more robust.
    
    LikeLiked by 1 person
    - 6
      
      hoakley on March 9, 2023 at 7:42 pm
      
      Although Apple’s servers have had their moments in the past, it was been a long time since there seems to have been any general problem. This is helped considerably by caching, but there the danger is that macOS can cache too long, so allowing apps with revoked certificates to run.
      Howard.
      
      LikeLike
    - 7
      
      Rick on March 9, 2023 at 9:01 pm
      
      It’s better than it was, but it was only yesterday that I couldn’t open Affinity Publisher on my m1 Mac due to this issue. It’s frustrating when you need to use an app and it refuses to run for no apparent reason.
      
      LikeLiked by 1 person
    - 8
      
      hoakley on March 9, 2023 at 9:58 pm
      
      I’m sorry to hear that. Is that an App Store version, or bought direct?
      The App Store has a different system of certificates, in that each app is actually signed by an Apple certificate, and they’re not normally notarized either.
      When certificate validations run into trouble, the user is often told that the app is damaged, and should be trashed, which must be one of the least helpful errors to report.
      Howard.
      
      LikeLike
9

Rick on March 9, 2023 at 10:20 pm

It was bought direct from Affinity as the licence also includes the Windows versions. I’ve seen the damaged app message when trying to start app store apps as well, and, as you say, it’s a pretty unhelpful message. Perhaps it should say something like “unable to contact Apple’s servers for app verification. If you trust the app, would you like to open it anyway?”.

Thanks once again for your enlightening articles on what happens under the hood of our Macs, it’s appreciated.

LikeLiked by 1 person
- 10
  
  hoakley on March 9, 2023 at 10:47 pm
  
  Thank you.
  Howard.
  
  LikeLike