Tag: mojave

Categories
Uncategorized

Finding 32-bit applications on Macs

In macOS 10.13 (High Sierra), Apple started warning users about 32-bit applications by saying those applications were "not optimized" for their Macs. The warnings continued in macOS 10.14 (Mojave). Starting with macOS 10.15 (Catalina), 32-bit applications will cease working altogether.

Hopefully, vendors still producing 32-bit applications for Macs will get their acts together and create 64-bit versions soon.

In the meantime, you might want to check your Macs for what 32-bit applications they have installed so you can pressure vendors to update their apps, start looking for 64-bit alternatives to those apps, or consider whether you even still need to use those apps.

Checking for 32-bit apps on an individual machine

I'm not sure how useful this would be to Mac admins, but you can check for 32-bit applications on a single machine by going to System Information.app

Then scroll down on the left side to find, under Software, Applications.

It might take a while for the list to load.

Once the list is loaded, you can sort by 64-bit (Intel), and then sort again, so all the No entries are at the top.

Checking for 32-bit apps for multiple machines via MunkiReport

If you're using Munki and MunkiReport, you can go to Listings > Applications to see which apps in your fleet are 64-bit or not.

If you want to query the MunkiReport database directly, you can also run

SELECT DISTINCT path
FROM applications
WHERE has64bit=0
ORDER BY name, path
and that will give you only distinct results. You could go distinct with name instead of path if you don't want the actual name of the app bundle but just the name of the app.

Acknowledgements

Thanks to eholtam and gmarnin on the MacAdmins Slack for pointing me to the right place in MunkiReport.

Categories
Uncategorized

TCC in Mojave doesn’t prevent deleting local folders for AD-bound Macs

Note: We're currently using a setup of Force local home directory on startup disk for AD-bound Macs instead of Create mobile account at login or Use UNC path from Active Directory to derive network home location—so if you're using either of those other options, your mileage may vary—definitely do some testing! This is also as of 10.14.5 (Mojave); Apple very well may change things for 10.15 (Catalina) and beyond.

I was worried that TCC would mean we wouldn't be able to delete local home folders for AD users without jumping through some code signing hoops, but apparently a regular old

/bin/rm -rf /Users/USERNAME
command in a root-run script seems to do just fine there, whereas it would choke on a regular (non-AD) user with an Operation not permitted TCC error

If you do need to code-sign a script, though, eventually, you may want to have a look at Code Signing Scripts for PPPC Whitelisting. It has a detailed walkthrough using Outset as an example.

Categories
Uncategorized

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\ Mojave.app --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\ Mojave.app/Contents/Resources/startosinstall --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 ###