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.

Here's our latest update to the @Avid user community from CEO @JeffJRosica and CPO Dana Ruzicka with some helpful advice for our creative tools users running @MediaComposer on Mac Pro.

More info on OS recovery ▶️ https://t.co/DsUk7qdf39https://t.co/NKt6yMHvSZ

— Avid (@Avid) September 24, 2019

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.

MacAdmin 101: The root user account

An issue that can pop up for new Mac admins is whether or not to enable the root account on the Macs in your environment. By default, the root account on OS X and macOS is a disabled account with the following settings:

Display name: System Administrator
Account name: root
UID: 0
Home directory: /var/root
User shell: /bin/sh

The root account is the superuser for a Unix-style operating system like OS X and macOS and Unix is designed to let the root account have total access to everything. When asking what root can do on a system, it may be better to ask what root cannot do because that list is very, very short. Because the root account has enormous power on a Unix system, you may believe that enabling the root account and using it for your system administration tasks is a no-brainer.

In fact, the opposite is the case: It’s better to leave the root account disabled and not use it for system administration.

Why should you avoid logging into the root account and running tasks from there?

• Mistakes happen – When logged in as the root account, you have total access to the system and anything you run while logged in as root will just happen. That also means you can do a lot of damage if you make a mistake.
• Malware and software bugs – Being logged in as the root account means that all the applications you’re using are running with the root account’s privileges. That means every vulnerability and bug in those applications can potentially cause havoc on your system because anything that’s executing an undesired behavior or exploiting a vulnerability in a particular application is doing so using the root account’s rights to go anywhere and do anything on your system.
• Auditing: If multiple people are logging into the root account and using it for system administration, that means that the account in question isn’t necessarily tied to a single person and actions taken while logged into the root account aren’t necessarily logged. That makes it harder to figure out after the fact who did what if there’s a problem.
• It’s not necessary: The sudo command line tool is available and installed by default on both OS X and macOS. sudo is a Unix program which allows a user with the correct sudo rights to execute a command using the security privileges of another user account, with the root account’s security privileges being used by default.

Using sudo is safer than using the root account for the following reasons:

• Nobody needs to know the root account’s password – sudo prompts for the current user’s password and will check to see if the user which is trying to use sudo has the necessary rights for sudo to run the requested commands with root privileges.
• The granting of root privileges is temporary – By default, sudo will time out after fifteen minutes and will require re-authentication before running commands again.
• Only those commands run via sudo are using root privileges – Only the commands run using sudo will be run with root privileges. Meanwhile, commands run without sudo are being run without root privileges, which reduces the potential for damage from making a mistake.
• sudo use is logged – When a command is executed using sudo, the command and the account which used sudo to run it are logged. Likewise, unsuccessful attempts to run commands with sudo are also logged. This provides an easy way to look up which commands were run and who ran them.

For more information on using sudo, see below the jump.

Session videos now available from X World Conference 2016

The good folks behind X World have now posted the session videos from X World 2016. All are accessible from the X World 2016 YouTube playlist page, which is available via the link below:

https://www.youtube.com/playlist?list=PLUzsToqd-eE8-yMclT6qzh2lUP-XI0uvD

As all the session videos have been posted to YouTube, I’ve linked my OS X Security: Defense in Depth session here:

The Documentation – Why All The Cool Kids Are Doing It session is linked here:

Slides from the “OS X Security – Defense in Depth” Session at X World 2016

For those who wanted a copy of my security talk at X World 2016, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/XWorld2016SecurityPDF

Keynote – http://tinyurl.com/XWorld2016SecurityKeynote

Apple security update blocks Apple Ethernet drivers on OS X El Capitan

Over the weekend, Apple released an update for a kernel extension blacklist used by System Integrity Protection on OS X El Capitan. This blacklist is a security measure to help Apple block kernel extensions which have been found to be harmful or problematic for OS X. This update belonged to a category of updates which Apple has set to install automatically and in the background, so its installation would have been both automatic and invisible.

Unfortunately, this blacklist update appears to have inadvertently contained the kernel extension information for Apple’s own Ethernet drivers. This is a problem because blocking the Ethernet drivers means your Mac will not be able to connect to your network via an Ethernet connection.

Apple appears to have quickly recognized the problem and has released a follow-up update which fixes this issue.

---

Update – 10-28-2016: Apple has posted a knowledgebase article about this issue: https://support.apple.com/HT6672

---

The good news:

1. This issue does not affect your Mac’s WiFi connection. WiFi has separate drivers which were not affected.
2. If the Ethernet drivers are blocked, but the Mac has not yet rebooted, your Ethernet connection will remain working until the next time the Mac reboots.
3. The follow-up update which fixes the problem may already be installed on your Mac.

For more information, see below the jump.

Updated System Integrity Protection status reporting script

After writing a Casper Extension Attribute script to report on the status of System Integrity Protection, I realized that I hadn’t accounted for reporting SIP’s custom configurations. These are configurations where SIP is enabled, but one or more of SIP’s protections or restrictions has been disabled. I’ve now updated the script to also report on the following SIP configurations:

• Kext Signing: disabled
• Filesystem Protections: disabled
• NVRAM Protections: disabled
• Debugging Restrictions: disabled
• DTrace Restrictions: disabled

For more details, please see below the jump.

Casper Extension Attribute script to report System Integrity Protection status

To follow up on Apple’s changing the output of csrutil status when System Integrity Protection (SIP) is disabled, I’ve posted the following Casper extension attribute to my GitHub repo to report on whether SIP is enabled or disabled.

	#!/bin/bash
	osvers_major=$(sw_vers -productVersion | awk -F. '{print $1}')
	osvers_minor=$(sw_vers -productVersion | awk -F. '{print $2}')
	# Checks to see if the OS on the Mac is 10.x.x. If it is not, the
	# following message is displayed without quotes:
	#
	# "Unknown Version Of Mac OS X"
	if [[ ${osvers_major} -ne 10 ]]; then
	echo "<result>Unknown Version of Mac OS X</result>"
	fi
	# Checks to see if the OS on the Mac is 10.11.x or higher.
	# If it is not, the following message is displayed without quotes:
	#
	# "System Integrity Protection Not Available For" followed by the version of OS X.
	if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -lt 11 ]]; then
	echo "<result>System Integrity Protection Not Available For `sw_vers -productVersion`</result>"
	fi
	if [[ ${osvers_major} -eq 10 ]] && [[ ${osvers_minor} -ge 11 ]]; then
	# Checks System Integrity Protection status on Macs
	# running 10.11.x or higher
	SIP_status=`/usr/bin/csrutil status | awk '/status/ {print $5}' | sed 's/\.$//'`
	if [ $SIP_status = "disabled" ]; then
	result=Disabled
	elif [ $SIP_status = "enabled" ]; then
	result=Active
	fi
	echo "<result>$result</result>"
	fi

view raw

gistfile1.txt

hosted with ❤ by GitHub

The script has the following functions:

If the Mac is running 10.10.x or earlier

The script reports System Integrity Protection Not Available For and then reports the relevant version of OS X. For example, the script returns the following output on a Mac running OS X 10.10.5:

System Integrity Protection Not Available For 10.10.5

If the Mac is running 10.11.x or later

This script uses csrutil status to check SIP’s status. If System Integrity Protection is disabled, the script returns the following output:

Disabled

If System Integrity Protection is enabled, the script returns the following output:

Active

For those interested, the script is available on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/check_system_integrity_protection_status

System Integrity Protection’s csrutil status’ message change for OS X 10.11.2

In order to check whether System Integrity Protection (SIP) is enabled or disabled on a Mac running OS X El Capitan, you can use the csrutil command to report on SIP’s current status. For example, to learn if SIP is enabled or disabled, run the following command:

csrutil status

This command can be run without root privileges and will tell you if SIP is on or off.

If SIP is enabled on 10.11.0 or higher, you should receive the following message:

System Integrity Protection: enabled

If SIP is disabled on OS X 10.11.0 or 10.11.1, you may receive a confusing message which indicates that SIP is enabled, followed by a list of individual SIP functions which are disabled. If all functions listed are showing as being disabled, SIP is actually completely disabled; it’s just confusingly worded.

It appears that Apple has updated the status message on OS X 10.11.2 to make it much more clear when SIP is disabled. On 10.11.2, if SIP is disabled, you now should receive the following message:

System Integrity Protection: disabled

“OS X Security – Defense in Depth” session video from JAMF Nation User Conference 2015 now available

JAMF Software has posted the session videos for from JAMF Nation User Conference 2015, including the video for my OS X security session.

For those interested, all of the the JNUC 2015 session videos are available on YouTube. For convenience, I’ve linked my session here.

Slides from the “OS X Security – Defense in Depth” Session at MacTech Conference 2015

For those who wanted a copy of my security talk at MacTech Conference 2015, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/MT2015SecurityPDF

Keynote – http://tinyurl.com/MT2015SecurityKeynote