Using Santa to block macOS upgrades

In the past, I’d used the fake installer approach to stop users from upgrading to the newest macOS version.

But with macOS 10.14 (Mojave), I started blocking using Santa (see Using Santa to block an .app for more details on general Santa use). It’s likely this Santa-blocking approach also works for High Sierra and Sierra as well—I just haven’t tested it on those.

Just download Mojave to your Mac, and then run

santactl fileinfo /Applications/Install\ macOS\ –key SHA-256
to get the hash to block.

Then run a modified version of this command (substituting in the actual SHA-256 hash for the placeholder) to add it to the Santa blacklist:

/usr/local/bin/santactl rule –blacklist –sha256 “actuallonghashyougotfromthepreviouscommand

We were able to test this on two Mojave installers downloaded using two separate Apple IDs, so the binary seems to be the same regardless of which Apple ID is used to download it.

If a user then tries to run the Mojave installer, she or he will see a message like this:

Again, since it’s based on the binary (and since you don’t want to block by Apple certificate—which you may not be able to do anyway with Santa?—so you have to block by binary), you would have to create a new rule for every new macOS installer that comes out (10.14, 10.14.1, 10.14.2, 10.14.3… 10.15, 10.15.1… 10.16… and so on).

Special Note

Thanks to @elios (on Mac Admins Slack) for pointing out that this probably would not block the startosinstall binary from running. I was able to test and verify blocking the .app binary does not, in fact, block the startosinstall binary from running.

Also, by default, Santa will get the binary for InstallAssistant_springboard. If you want to be super aggressive, you might also want to block the InstallAssistant and InstallAssistant_plain binaries. Otherwise, the user can still run those two to get the GUI assistant to launch up.

So you really have to ask yourself how aggressively you want to block Mojave. Are you preventing users from just accidentally upgrading? Or do you want to prevent from upgrading even the most determined users who have admin privileges?

If you want to block startosinstall as well, you can do that. Just find (and subsequently block) the SHA-256 hash it:

santactl fileinfo /Applications/Install\ macOS\ –key SHA-256
santactl rule –blacklist –sha256 “actuallonghashyougotfromthepreviouscommand
One advantage you get from not blocking startosinstall is that you can still block users from double-clicking to install Mojave but not have Santa try to block Munki from installing Mojave, even if you have the InstallAssistant_springboard blocked.

If you block startosinstall, then try to install the upgrade with Munki, you’ll see it mount the .dmg, then stop. The log entries will look something like this:

### Beginning os installer session ###
Starting macOS upgrade…
Mounting disk image Install macOS Mojave-10.14.2.dmg
[Errno 1] Operation not permitted
Starting macOS install failed with return code 1
ERROR: ——————————————————————————
ERROR: [Errno 1] Operation not permitted
ERROR: ——————————————————————————
ERROR: Error starting macOS install: startosinstall failed with return code 1
### Ending os installer session ###

6 responses to “Using Santa to block macOS upgrades”

  1. Just tried doing this as I found it rather amusing.

    You’ll need to block the stub installer as well. I think you can force that to download by attempting to upgrade in the App Store without being signed in to an Apple ID.

    • Nope. When I downloaded it without being signed in with an Apple ID, I still got the full installer instead of the stub. Any other ways to get the stub?

      • not sure – maybe someone on slack knows.

        Here is the SHA256 for what I just pulled down though.


        # Mojave 10.14.0
        # Installer v. 14.0.22
        /usr/local/bin/santactl rule –blacklist –sha256 “590a8fda56798b456ccc4225ef62aea010c945d17bb4a452bf3f544fdba241d6”

        # Block Stub installer 14.0.21
        /usr/local/bin/santactl rule –blacklist –sha256 “f8268081ab7dcee0f7af9b3c63aa9635ddb3e8697e29d5eaf167d0073f92364e”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.