Gatekeeper was the centre of attention in Garret Jacobson’s presentation in session 701 of WWDC last week. I’ve been studying carefully what he said and integrating it with what we already know about Gatekeeper checks in Mojave, and in this article try to explain what is changing.

The name Gatekeeper is applied to a group of security features which together are designed to prevent malicious software from running in macOS, without stopping the user from being able to do what they wish. That neatly encapsulates the conflict between wanting to block everything apart from the truly trusted, and having an open house in which any passing malware can share.

Apple sees there being four key functions to Gatekeeper:

• to scan executable code for evidence of known malicious software;
• to validate code signatures and ensure the app hasn’t been tampered with;
• to validate the identity of software and ensure it matches the user’s policy set in the Security & Privacy pane;
• to display the first run (or first launch) dialog to ensure that the user wants to run the software.

What actually happens in Mojave is rather more complex, though. Assuming that an app has had a quarantine flag attached to it when it was downloaded from an Internet source, and that it’s opened via LaunchServices (most commonly the Finder), it undergoes a full signature check, malware scan by XProtect, check against user policy, then passes to user consent.

There are other circumstances in which parts of this process are also invoked, particularly when an app (with its quarantine flag cleared, or without any quarantine flag) is run from a previously unknown path by LaunchServices. Although no XProtect scan then takes place, the signature is checked.

None of this applies, though, to code which is run without LaunchServices being involved: command tools run from Terminal, for example, don’t pass through any of those steps at all.

The process for apps in Mojave is summarised in the diagram below.

Among the changes in Catalina are:

• first run checks on quarantined items apply equally to code launched without involving LaunchServices;
• whenever software is launched without a quarantine flag being set, XProtect scans it for known malicious software;
• for software signed on or after 1 June 2019, notarization checks are performed in addition to signature checks.

Unfortunately, I’m still unable to find any description by Apple in documentation or a WWDC presentation of the full signature check which takes place when an app is opened by LaunchServices from a previously unknown path. I must assume that this behaviour continues in Catalina. The addition of a mandatory XProtect scan therefore means that an app launched by LaunchServices from a new path undergoes full signature and XProtect checks, exactly the same as if it had a quarantine flag set, although there’s no first run dialog at the end of it. I also assume that the first run signature check is still performed by Apple Mobile File Integrity (AMFI).

The new scheme for Gatekeeper functions in Catalina is as shown below.

There are several important take-home messages. For anyone who writes and distributes command tools, or other software which doesn’t get launched by LaunchServices, Catalina expects you to harden, sign, and notarize your software too, if it could attract a quarantine flag during delivery. This is a new requirement: although users will still be able to run unsigned command tools, they may find yours easier to get through first run if you meet these new requirements, and in the longer term that will become more important. I’m going to look at what’s involved in that tomorrow.

If you currently deliver unsigned software over the Internet, you should clearly now be considering how you can sign it, and preferably harden and notarize it. Although users can still run unsigned apps and other software, they cannot provide the same level of protection as signed, hardened and notarized products. Perhaps now is the time to address that.