Archive

Archive for the ‘Notarization’ Category

Verifying installer package signing and notarization using pkgutil

January 20, 2023 Leave a comment

Recently I needed a way to verify whether an installer package was signed and notarized. I’ve been using Apple’s stapler tool as my usual go-to for verifying notarization. However, the stapler tool needs for Xcode to to be installed and I needed a solution that worked regardless of Xcode or the Xcode Command Line Tools being installed on the Mac in question.

After some digging, I found that pkgutil‘s check-signature function on macOS Monterey and later works great for this and doesn’t have any dependencies on Xcode or the Xcode Command Line Tools. The pkgutil tool is installed as part of macOS and the check-signature function displays the following on Monterey and later:

If a package is not signed:

Screenshot 2023 01 20 at 10 25 38 AM

If a package is signed with a certificate:

Screenshot 2023 01 20 at 10 24 52 AM

If a package is signed with a certificate and trusted by Apple’s notarization service:

Screenshot 2023 01 20 at 10 23 29 AM

To use the check-signature function, you should be able to use the command shown below (substituting /path/to/installer.pkg with the actual directory path of the installer package you want to check.):


/usr/sbin/pkgutil –check-signature /path/to/installer.pkg

view raw

gistfile1.txt

hosted with ❤ by GitHub

Notarization on macOS Catalina and IT auditing

October 3, 2019 Leave a comment

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

Screen Shot 2019 10 03 at 11 57 06 AM

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):

Screen Shot 2019 10 03 at 12 04 51 PM

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.

%d bloggers like this: