Archive

Archive for the ‘System Integrity Protection’ Category

Google Keystone update breaks Macs’ ability to boot if System Integrity Protection is disabled

September 25, 2019 6 comments

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.

Image 2

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.

Read more…

MacAdmin 101: The root user account

July 26, 2016 Leave a comment

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

Screen Shot 2016 07 26 at 3 03 58 PM

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 passwordsudo 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.

Read more…

Session videos now available from X World Conference 2016

July 26, 2016 1 comment

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

July 7, 2016 Leave a comment

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

February 28, 2016 9 comments

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.

Read more…

Updated System Integrity Protection status reporting script

December 18, 2015 Leave a comment

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.

Read more…

Casper Extension Attribute script to report System Integrity Protection status

December 16, 2015 Leave a comment

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.

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

%d bloggers like this: