One of the changes Apple is introducing in macOS Catalina is the notarization requirement for code in the following categories:
- All apps signed after June 1st, 2019
- Signed executable code which are undergoing first run checks (this check would be triggered by the executable having a com.apple.quarantine extended attribute.)
Note: Signed executable code can take many forms, including command-line binaries or other tools which don’t fit into the usual macOS app category. In this post, I’m going to be using “executable” or “executable code” in this post as shorthand for “It’s not an app, but you can sign, notarize and run it.”
Notarization is commonly thought of as Apple doing a malware scan on the app / executable in question, but it’s also more than that. Notarization also includes a code hardening process for the app or executable, which sets up the app or executable code to run in a protected environment. What protections are provided? According to Apple:
- App / executable can’t create executable memory without the app / executable being associated with a code signature.
- When the OS is reading code or data from drive storage, all the data being read in to the running app or executable must match the app /executable’s code signature.
- Code which is modified in memory and which no longer match the app / executable’s code signature can’t be executed.
- Protection provided against code injection and/or dylib hijacking.
While there are entitlements provided by Apple to allow apps / executables to bypass these protections, they’re embedded as part of the notarization process and can’t be changed later without breaking the code signature. Meanwhile, notarization is for the life of that particular app / executable code. It’s not just checked once, like has been the case with Gatekeeper’s code signature check for apps / executables on previous versions of macOS.
How does this relate to IT auditing and making it less painful? Well, imagine you had an auditor come to you and say “I need you to check and verify that all third-party apps used in your environment have been scanned for malware.”
Holy cow. That’s a huge requirement.
Or it was. Notarization provides exactly that capability and it can be verified on-demand using the stapler tool. Even better, since the OS is what’s requiring notarization for apps, it’s automatically handling compliance for you. Meanwhile, notarization’s protected environment limits considerably the ability of malware to hijack notarized apps. That likely would check a few more malware-related compliance boxes on the auditor’s checklist.
For an example of this, let’s take a look at the Australian Cyber Security Centre’s guidance for application whitelisting. For enforcement mechanisms, two of them are provided by macOS Catalina’s handling of notarized apps:
- Cryptographic hash rules
- Publisher certificate rules
The US’s National Institute of Standards and Technology provides similar guidance (please see Section 2.2.1 File and Folder Attributes of NIST SP 800-167):
This is not to say that you can hold up a “Notarized!” sign to the auditor, watch the auditor leave after just tossing the checklist aside and commence the post-audit party. But for those folks who have to undergo regular compliance auditing, I would recommend you examine your auditing requirements carefully to see which IT audit controls on your list now get handled automatically on macOS Catalina with its notarization requirements.