Apple hides a powerful feature behind a menu in System Settings > Privacy & Security. That menu is the visible part. Behind it, Apple manages a good deal more to protect you against malicious software.
The point of knowing more is twofold: First, to recognize when something’s gone wrong. Second, to bypass protections in the limited cases in which you need to.
Manage app sources
The Gatekeeper feature was introduced years ago, and affects how you install and use software. Gatekeeper examines downloaded apps when they are first launched, including custom installers from a developer. (Apple has a generic installer that most apps rely on.) If you have set your app launch preference to App Store only, macOS tells you that you can’t open a given app. Click Show in Finder to reveal the app.
However, there’s a workaround if you want to be able to open just some of these apps. With Gatekeeper set to App Store only, go to System Settings > Privacy & Security. You will see this message: “‘App Name’ was blocked from use because it is not from an identified developer.” That much we know. But there’s also an Open Anyway button to the right of this message.
Click the button. Once that’s clicked, your Mac launches the app with a dialog that asks you to confirm you really, really want to open it. Click Open to proceed.
This App Store bypass seems clunky, but it’s consistent. If you have locked a Mac account down (for a kid, say, or a client or parent) without administrative permissions to make changes, this workflow for launching a non–App Store app still won’t let them. However, if you’re the captain of your own ship, this is a simpler set of steps than switching your Gatekeeper App Store preference to allow identified developers and then switching it back again.
Gatekeeper can also reject launching an app in these circumstances:
- The app wasn’t notarized, an extra security check (explained below) that Apple made mandatory years ago.
- You allow non–App Store apps to launch, but this app is unsigned, which means it hasn’t gone through the extra pass of validation described below, including notarization.
- The app is or contains known malware or other harmful software, and Apple blocks it from running altogether.
- Something is wrong with the app, such as it having been tampered with, so it won’t launch, and you will be warned.
Gatekeeper’s point is to prevent apps from running that, more or less, don’t digitally smell right according to multiple characteristics. It is worth understanding app signing and notarization to see what that buys you. If everything’s OK, your Mac launches the software.
Apple software and components always launch unless macOS detects they were tampered with. There’s no step to approve them.
For apps outside the App Store with Gatekeeper set to allow apps from identified developers, you still have one more step: you’re informed the app was downloaded from the internet and told that it was cleared for takeoff, but you must click Open to proceed. This may seem like overkill, but it’s one additional way that Apple ensures you haven’t been tricked into running software you didn’t intend to.
Apple also lets you know when an app is on a disk image instead of copied to your Applications folder, in case the disk image window tries to mislead you about its contents.
But wait! There’s more! If you do not check “Don’t warn me when opening applications on this disk image,” macOS…warns you when you open the application, requiring yet another click of Open.
If the app you try to run contains malware, Apple provides a unique warning, one I’ve never seen, and had to source from an Apple support note. This dialog also lets you report the item to Apple.
App signing and notarization
Each developer who has joined Apple’s $99-per-year Apple Developer Program receives a unique digital certificate that binds their identity with cryptography to prevent tampering and impersonation. When building an app in Apple’s Xcode development environment, the creator can use that certificate to sign the app.
This signature results from feeding the compiled binary version of the app—the actual code package you install and that runs—through a hashing routine, an iterative cryptographic process that produces a modest-length number (the hash) that appears innocuous. However, hashing is designed so that if even a single byte is changed in the entire source material (here, the app)—even if the number 8 becomes the number 9—the resulting hash is dramatically different. With modern hashing algorithms, there’s no way for a malicious party to modify an app, sign it, and get the same signature as the valid app.
Neat, huh? Hashing underpins a shockingly vast part of internet and real-world encryption, including all HTTPS web connections, secure email, and vastly more.
That hash is then countersigned by secret keys tied to certificates only Apple possesses, which lets macOS validate the signature and makes it impossible to forge the hash—otherwise, that would be a gaping loophole.
Notarization is a separate and distinct step that applies both to an app and any third-party components and libraries it makes use of. Notarized apps, non-Apple installers, kernel extensions, and other bits of code have been scanned by Apple for known malware and none was found. But it also includes other security scanning, such as ensuring apps and components are hardened, which means there’s no way for parts of the app to be swapped out by malicious software while they’re running.
The text that appears in the launch dialog for non-App Store apps confirms notarization: “Apple checked it for malicious software and none was detected.”
Apple requires signing and notarization for apps in the App Store and those distributed directly by developers. App Store apps also go through review by human beings for content and purpose, which is separate from these automated scanning and signing operations.
A signed and notarized app doesn’t look any different to us, as users, from an unsigned app (whether notarized in part or whole), but it contains extra data that lets macOS determine:
- Integrity: Whether the app has been changed since it was built
- Identity: Which developer created (and signed) an app
- Access: Which system resources the app may access
Each of these attributes helps to protect your security.
Let’s start with integrity. If an attacker were to modify an app after it was signed—for example, inserting malicious code while it sat on the developer’s web server or even after you started using it—Gatekeeper would notice the change, as the hash wouldn’t match, and it would prevent the app from running.
Gatekeeper always prevents signed apps that have been altered from running, even if they ran fine before.
Next, suppose someone signed up for the Apple Developer Program and started delivering malicious software, signed with their certificate. The identity feature kicks in—once Apple discovers that the developer is distributing dangerous software, Apple can revoke that certificate, telling Gatekeeper not to let any software signed with that certificate launch. Gatekeeper checks Apple’s revocation list every time an app launches to make sure it’s still valid.
A malicious party using a legitimate certificate isn’t a hypothetical situation, though it’s rare in practice. In 2017, a phishing message convinced people to download and open a ZIP file, then launch an app inside it, and further conned them into entering an administrative password. The ne’er-do-wells had signed up for a developer account, and the app was signed. Apple revoked the certificate, defusing its potential.
The third aspect, access, involves system resources such as the keychain. If you grant an app permission to store information in the keychain or access it afterward, you don’t want to have to keep doing so every time you update the app.
But if you install a new version of an app that was signed with the same certificate, Gatekeeper treats it as the “same” app for the purpose of granting access to system resources, and you won’t be prompted for keychain access again.
Conversely, if someone altered the app or gave you an unsigned and therefore unauthorized version, it wouldn’t be able to access your keychain without your permission—in fact, Gatekeeper should prevent it from launching at all, because it won’t pass the signing test.
All of this reduces your risk of inadvertently running malicious software. If an app is not in the App Store and has not been signed and notarized, there is one way to bypass Gatekeeper.
Beware bundled adware
A slimy practice that peaked a few years ago was for download sites to take otherwise safe and trustworthy software from someone else and wrap it in their own custom installer with a type of malware known as adware—which, among other things, displays intrusive ads, even if you block pop-up windows and use ad-blocking browser extensions in your web browser. Here’s how to protect yourself:
- Avoid free software download sites. If the app isn’t in the Mac App Store, download it directly from the developer. (The sole exception is Setapp, a multi-developer subscription service that has a single app that can install multiple apps for you.)
- Don’t override Gatekeeper unless you’re sure it’s from an absolutely trustworthy source.
- If an installer asks if you want to install any extra software (especially if it’s “sponsored”) or browser extensions, or make changes to your browser settings, say no.
While the problem seems to have waned for many years, I still receive scattered emails messages from readers who have installed adware without intending to. Be vigilant about the source of your software.
