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
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.
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:
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:
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.
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:
- This issue does not affect your Mac’s WiFi connection. WiFi has separate drivers which were not affected.
- 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.
- The follow-up update which fixes the problem may already be installed on your Mac.
For more information, see below the jump.
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.
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:
If System Integrity Protection is enabled, the script returns the following output:
For those interested, the script is available on my GitHub repo:
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:
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