Archive
Google Keystone update breaks Macs’ ability to boot if System Integrity Protection is disabled
On the evening of Monday, September 23rd, a number of film and TV editors started reporting that their workstations were not rebooting successfully. The problem was initially blamed on the Media Composer software sold by Avid.
On September 24th, more instances were reported and it became clear that this was not an issue restricted to Macs with Media Composer installed. After extensive checking and testing, the folks in the MacAdmins Slack were able to narrow down the issue to an update to Google’s Keystone software, which Google uses to update Google Chrome and other Google products on macOS.
The now-pulled Keystone update attempts to remove the /var symlink, which is usually protected by Apple’s System Integrity Protection (SIP) security feature.
On Macs where SIP was disabled, this protection did not apply and the Keystone update was able to remove the /var symlink. This symlink is not a directory itself, but points to another directory (/private/var) which contains software necessary for the operating system to boot and function correctly, so removing the /var symlink rendered the affected Macs unbootable.
As mentioned previously, Google has pulled the problematic Keystone update and has published instructions on how to remediate affected Macs. For more details, please see below the jump.
Identifying Self Service policies with blank descriptions
As part of setting up Self Service policies in Jamf Pro, it’s nice to include a description for your customers of what they’re getting when they select a particular Self Service policy.
However, sometimes folks forget to add these descriptions and it can be hard to figure this out later which ones were missed without manually checking each policy.
To help with situations like this, I have a script which does the following:
- Checks all policies on a Jamf Pro server.
- Identifies which ones are Self Service policies which do not have descriptions
- Displays a list of the relevant policies
For more details, please see below the jump.
Creating macOS configuration profiles with encrypted payloads
Recently, I was asked to create a configuration profile with an encrypted payload. This is a payload where the settings installed by the profile are not readable when you look at the .mobileconfig file. Instead, the payload with the settings is encrypted and are only readable once the payload contents are decrypted using the private key of a certificate which is also installed on the Mac in question.
In researching how to do this, I found that Apple’s documentation on encrypted payloads is very sparse and largely consists of the following (from https://developer.apple.com/documentation/devicemanagement/using_configuration_profiles):
Example commands for CMS encryption of the property list are not provided in Apple’s documentation, but it is possible to use /usr/libexec/mdmclient to encrypt profile payloads:
https://mosen.github.io/profiledocs/troubleshooting/mdmclient.html#encrypt
To see how this works, let’s go through the process of setting up a certificate which can be used for encrypting a profile followed by using that certificate to encrypt the profile. For more, please see below the jump.
Disable screenshots and screen recordings on macOS Mojave
In certain circumstances, like taking school tests or handling sensitive documents, it may be necessary to disable the ability to create screenshots or make screen recordings. For those who need to do this, it’s possible to set this with a profile.
PayloadType: com.apple.applicationaccess
Key: allowScreenShot
Type: boolean
Once a profile has been built and applied to a Mac running macOS Mojave, trying to create a screenshot or screen recording will result in the following message.
For more details, please see below the jump.
Der Flounder 
Recent Comments