Tag: mac

Using Santa to block an .app

Acknowledgements

Special shoutout to @bur on the Mac Admins Slack for help with some command-line syntax.

Santa can be complicated, but doesn't need to be

Google has a project on GitHub called Santa, which is quite powerful and complicated. As the project's readme says, though: Documentation: This is currently limited..

I just wanted to do something simple: block an app, but I didn't see any straightforward documentation on how to do that. The closest I could find was the docs on certificate rules, but that was a bit incomplete.

So, first of all, something I was confused about at first was whether a configuration profile was necessary or not. It is not necessary. There are some default settings that just go by themselves. You need to configure settings only if you need to configure settings.

Blocking an app by certificate

If you have a blocking application rule, you can block by binary or by certificate. By binary may not be as helpful, because newer versions of an app will be a different binary. Let's say you want to block MacKeeper by certificate. (Install Santa first, so you can actually use it, including the santactl command.)

santactl fileinfo /Applications/MacKeeper.app --key "Signing Chain"
Signing Chain:
1. SHA-256 : 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614
SHA-1 : 2664b71c3db787226ff9715da4de32e9ad3e364f
Common Name : Developer ID Application: KROMTECH ALLIANCE CORP. (64424ZBYX5)
Organization : KROMTECH ALLIANCE CORP.
Organizational Unit : 64424ZBYX5
Valid From : 2013/10/14 04:00:13 -0700
Valid Until : 2018/10/15 04:00:13 -0700

2. SHA-256 : 7afc9d01a62f03a2de9637936d4afe68090d2de18d03f29c88cfb0b1ba63587f
SHA-1 : 3b166c3b7dc4b751c9fe2afab9135641e388e186
Common Name : Developer ID Certification Authority
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2012/02/01 14:12:15 -0800
Valid Until : 2027/02/01 14:12:15 -0800

3. SHA-256 : b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024
SHA-1 : 611e5b662c593a08ff58d14ae22452d198df6c60
Common Name : Apple Root CA
Organization : Apple Inc.
Organizational Unit : Apple Certification Authority
Valid From : 2006/04/25 14:40:36 -0700
Valid Until : 2035/02/09 13:40:36 -0800

Then, add a block rule for it:

sudo santactl rule --blacklist --certificate --sha256 2df1460a9c76c4a63fa2d0d043fb0254f8fa69a99374f2a0b1e8eee885872614

You can always check on the other parameters by running

sudo santactl rule
which will output something like this:
No state specified

Usage: santactl rule [options]
One of:
--whitelist: add to whitelist
--blacklist: add to blacklist
--silent-blacklist: add to silent blacklist
--remove: remove existing rule
--check: check for an existing rule

One of:
--path {path}: path of binary/bundle to add/remove.
Will add the hash of the file currently at that path.
Does not work with --check. Use the fileinfo verb to check.
the rule state of a file.
--sha256 {sha256}: hash to add/remove/check

Optionally:
--certificate: add or check a certificate sha256 rule instead of binary
--message {message}: custom message

If you then try to run MacKeeper, you'll get a block message like this:

That's pretty much it. That isn't everything Santa can do. That's about the simplest thing you can do with Santa, but most of the documentation for Santa is about all of the other stuff you can do. I didn't see much about just how to simply block an .app, hence this blog post.

If munkiimport doesn’t generate an installer_item_hash in the pkginfo file

If you notice that running munkiimport on a .dmg doesn't result in an installer_item_hash generating, you might want to also run makepkginfo on that .dmg to double-check it's read-only:

makepkginfo /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg
WARNING: /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg is a writable disk image. Checksum verification is not supported.
WARNING: Consider converting /PATH/TO/REPO/pkgs/PROBLEMITEM.dmg to a read-only diskimage.

“Grant access” problem when trying to open Word docs

If you're trying to open a Word doc, and it keeps saying you don't have permission (even when you own the document), asking you to grant access to the document, and then still not giving you access; then just quit out of Word completely, and then launch it up again. The document should open fine after that.

Chrome Gmail unread messages not appearing in bold

We had a user whose unread emails were appearing as bold in Safari (with an ugly font) and not bold at all in Chrome (font looked okay), and we did some digging and found the solution was to enable the Arial Bold font in Font Book on the user's Mac, and it was all good.

Our best guess is that Safari couldn't find the font it wanted so substituted an ugly font but kept it bold, and Chrome couldn't find the font it wanted so substituted a decent-looking font but not bold.

Use the command-line to set a firmware password on macOS

For extra security, you can add a firmware password to Macs, especially since Find My Mac is essentially useless (unlike for iPads, which have an activation lock preventing thieves from reactivating the iPad after a factory reset) and DEP-to-MDM enrollments for Macs can even be avoided by thieves if they're resourceful enough.

If you have a laptop with a firmware password, you need that password to boot from anything except the startup disk. Combine that with FileVault encryption, and a stolen Mac is pretty much useless. Doesn't mean that you'll necessarily get it back, but the likelihood is higher if the device is useless to thieves.

You can, of course, enable the firmware password via Recovery Mode, but it's easier to do it from the command line:

sudo firmwarepasswd -setpasswd
You'll be prompted for the new firmware password. Afterwards, you'll need to reboot the machine for the change to take effect. (Be sure to make sure you have an actual startup disk selected in System Preferences!)

There are two modes for a firmware password: command and full. By default, the firmware password mode will be command, which means you'll be prompted for the password only if you boot from something other than the startup disk. If, for some strange reason, you want the mode to be full, it would mean you'd be prompted for a firmware password at every boot, regardless of what you're booting to.

A few other commands you might find useful...

sudo firmwarepasswd -check
checks to see if the firmware password is set.
sudo firmwarepasswd -verify
allows you to verify you have the correct password (without rebooting).
sudo firmwarepasswd -delete
deletes the firmware password. You'll need the current one to delete it, of course.

If you want to script firmware password setting, someone wrote a fairly simple script that does it. There's also firmware password manager, which is a far more sophisticated way to manage firmware passwords.

Nota Bene: If you enable a firmware password, you can get into target disk mode by holding down the Alt/Option key at boot, typing in the firmware password, and then holding down the T key. However, you will be unable to boot into Safe Mode unless you delete the firmware password.

Script AutoPkg trust verification and trust update process

Starting with version 1, AutoPkg began evaluating trust info for recipes, so you could see what changes were made to a recipe (if changes were made) and then accept the changes if you wanted to. Here is what the typical trust verification workflow looks like.

Whether running a list of recipes via script or via AutoPkgr schedule, I'd occasionally get error'ed recipes when trust was broken, have to manually run

autopkg verify-trust-info -vv NAMEOFRECIPE
and then, after review, run
autopkg update-trust-info NAMEOFRECIPE
and then run the recipe after updating the trust info:
autopkg run -v NAMEOFRECIPE
So I thought I'd take a stab at scripting the whole process. Basically my script updates all the repos (to see if there are changes), verifies trust info on each of the recipes in the recipe list, and then prompts the user to review changes and approve them or not, before running all the approved or unchanged recipes.

It's still in the early testing phase, but it seems to work so far....

Capturing new FileMaker Pro updates for macOS

For older FileMaker Pro versions, there used to be downloadable updates on the FileMaker website, but starting with FileMaker Pro 15, they decided to have FileMaker updates on macOS go through FileMaker itself:

As you can see here, they expect your user to have admin privileges. If you're managing Macs (through Munki, for example), you may not give your users admin privileges or you may (even if your users have admin privileges) not want to bother with them running the updater themselves.

For some reason, Windows users get separate update installers. None for the macOS users, though, but we can be a bit tricky in capturing the installer.

First, find a Mac that you're not doing a silent install of FileMaker Pro on. Do a regular manual install on that one Mac and make sure you have AI_DISABLEUPDATENOTIFY=0 in your Assisted Install.txt file.

Then, on this test Mac, launch up FileMaker Pro.

Under Help, select Check for Updates....

Click Download Update

This is key here: do not click Install Update. Don't click Cancel either. Do not click anything. Just leave this dialogue up for now.

Open up /var/log/install.log and search for caches.

That should show you the location of the downloaded installer.

Go to that location and find the .pkg file. You can import that into Munki (or whatever you use to manage updates to your Mac fleet).

Fixing a broken MDM on OS X Server with Profile Manager

If you're getting errors like Websites are turned off. An administrator can turn them on using the Server application or the configuration for your ipad could not be downloaded invalid profile, try Reset Apache In OS X Server To Factory Defaults and then turn Websites and Profile Manager back on.

Skipping Apple updates in Managed Software Center manual checks

Why would you want to selectively disable Apple software updates?

Munki allows you to change a preference on client machines to check for and install Apple software updates.

This is pretty cool. It means I can bundle Apple software updates and third-party software updates together for my users.

But sometimes, it's a little frustrating when I'm helping a user to use Managed Software Center, and MSC checks for new updates but also decides to check for Apple updates... don't really need it to check for Apple updates then. Totally want Munki to check for Apple updates in the background and all the other times, just not when the user launches up MSC.

It's true if you've just checked very recently. you may see Skipping Apple Software update because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check, but even if it's been a while since the last check, I just don't want any check happening if the user has manually launched up MSC.

Use a Preflight script

Munki allows you to run preflight and postflight scripts during each Munki run. As Munki is out of the box, you are supposed to have one preflight script named preflight (no extension). If you use MunkiReport, though, as I do, you'll notice MunkiReport has the preflight script run a bunch of scripts in the preflight.d directory, which allows a bit more flexibility to add in various scripts instead of lumping them into one combined preflight script.

Script logic

Preflight scripts can use the runtype to do different things based on whether the Munki run type is an auto, logoutinstall, checkandinstallatstartup, installwithnologout, manualcheck, or custom.

What the script does is just check to see if there's a manualcheck and then turn the InstallAppleSoftwareUpdates preference off. If it's any other type of run, the script turns the preference on.

The actual preflight script

Here is the preflight script, which you can deliver as a payload to /usr/local/munki/preflight.d/ (or as /usr/local/munki/preflight if you don't have a preflight directory). You can create the .pkg using Packages, The Luggage, munkipkg, or even just pkgbuild.

If you want to make it based on another runtype you can change the logic there or tweak the script to use a time-based or date-based logic to run Apple updates less frequently. The possibilities are endless!