Last few weeks I have been diving into System Integrity Protection (SIP) part of OS X El Capitan to better understand it.
Most interesting for me was the discovery that when a Mac is booted from recovery you can edit the ‘restricted’ parts using the chflags command. According to Apple the permissions for system files will be repaired with system and security updates, but testing the 10.11.1, .2 and .3 combo updates did NOT repair permissions I changed with the example below.
Some applications require write permissions to folders that are normally restricted by SIP, so this seems a workaround for these applications, that is why I share my findings.
In this post I will show for Mac Admins how I used DeployStudio to run a script to change the permissions on a Mac System, and keep these ‘less-restricted’ permissions while SIP is enabled.
If you are new to this feature of 10.11, come to our Mac Security workshop (:-), or read this blog posts first: SIP by Rich Trouton.
Why or why not bypassing SIP
In a perfect world all App’s will be updated to function on 10.11 with SIP, in a less perfect world admins are sometimes forces to find a way to run an unsupported App on 10.11. Here is a workaround that could for some cases help bypassing SIP without disabling it completely. Disabling is always temporary, if a user clears the NVRAM SIP will be enabled. See the paragraph ‘Can you use this for your workflows?’ at the bottom to read my recommendations.
First I made a DS Runtime NetInstall image (server running 10.11.2/Server 5.0.15, from local disk, using DeployStudio 1.7.1).
I made a small script ‘tweak_SIP.sh’ to demo the possibilties of csrutil and chflags.
This script is avaible on GitHub
This script is shown here from DeployStudio Admin point of view.
The I created a simple workflow that deploys an 10.11.0 dmg created with AutoDMG, configured that image with a name and users, and run the script (NOT postponed!) as shown below:
The first step of the workflow: the restore task:
The second step of the workflow: the configure task:
The third step of the workflow: the generic script (NOT postponed) task:
Running the script
Running this workflow results in this log (parts of it)
Runtime.bin[ DeployStudio Runtime
Runtime.bin[ DSCore.framework version 1.7.1 (b151220), Copyright 2015 The DeployStudio Team.
Runtime.bin[ MAC address: 00:23:32:b0:c5:ce
Runtime.bin[ Network address: 10.0.0.230 (mac-w88488za1g0.local)
Runtime.bin[ Network interface speed: AUTOSELECT (1000BASET <FULL-DUPLEX,FLOW-CONTROL>)
Runtime.bin[ Operating System: Mac OS X Version 10.11.2 (Build 15C50)
Runtime.bin[ Date: 16/01/26 11:38:35
—- snip —-
Runtime.bin Macintosh model: MacBookPro5,1
Runtime.bin Boot ROM version: MBP51.88Z.007E.B06.1202061253
Runtime.bin Firmware ok!
Runtime.bin Running workflow:' -Restore and tweak SIP' (25B8F048-874F-48F0-9514-D5DA9D6952EF)
—- snip —-
Runtime.bin Generic task action:
Runtime.bin /tmp/DSNetworkRepository/Scripts/tweak_SIP.sh 2>&1
Runtime.bin - v1.0 (Tue Jan 26 12:39:25 CET 2016)
Runtime.bin This script will run: chflags norestricted on /System/ and /sbin/
Runtime.bin and chmod a+rw on /sbin with this Volume:
Runtime.bin /Volumes/Macintosh HD/System/
Runtime.bin SIP status and netboot list(s):
Runtime.bin System Integrity Protection status: enabled.
Runtime.bin Allowed NetBoot sources:
Runtime.bin SIP netboot list(s):
Runtime.bin - end
Runtime.bin -> Generic task action completed.
Runtime.bin Task successful (elapsed time: 0.01 minutes)
The resulting OS X permissions in test
After rebooting the deployed Mac the OS version is:
mbp5:~ ladmin$ sw_vers
ProductName: Mac OS X
SIP is enabled:
mbp5:~ ladmin$ csrutil status
System Integrity Protection status: enabled.
Allowed NetBoot sources:
Permissions on / when viewed with the ls -lO command:
mbp5:~ ladmin$ ls -lO /
drwxrwxr-x+ 36 root admin sunlnk 1224 Sep 17 00:02 Applications
drwxr-xr-x+ 58 root wheel sunlnk 1972 Sep 30 12:36 Library
drwxr-xr-x@ 2 root wheel hidden 68 Aug 22 14:35 Network
drwxr-xr-x@ 4 root wheel - 136 Sep 30 12:29 System
drwxr-xr-x 6 root admin - 204 Jan 26 03:42 Users
drwxrwxrwt@ 4 root admin hidden 136 Jan 26 03:47 Volumes
drwxr-xr-x@ 39 root wheel restricted,hidden 1326 Sep 17 00:07 bin
drwxrwxr-t@ 2 root admin hidden 68 Aug 22 14:35 cores
dr-xr-xr-x 3 root wheel hidden 4138 Jan 26 03:43 dev
lrwxr-xr-x@ 1 root wheel restricted,hidden 11 Sep 30 12:34 etc -> private/etc
dr-xr-xr-x 2 root wheel hidden 1 Jan 26 03:43 home
-rw-r--r--@ 1 root wheel hidden 313 Aug 22 19:35 installer.failurerequests
dr-xr-xr-x 2 root wheel hidden 1 Jan 26 03:43 net
drwxr-xr-x@ 6 root wheel sunlnk,hidden 204 Sep 17 00:04 private
drwxrwxrwx@ 59 root wheel hidden 2006 Sep 30 12:34 sbin
lrwxr-xr-x@ 1 root wheel restricted,hidden 11 Sep 30 12:34 tmp -> private/tmp
drwxr-xr-x@ 12 root wheel restricted,hidden 408 Sep 30 12:34 usr
lrwxr-xr-x@ 1 root wheel restricted,hidden 11 Sep 30 12:34 var -> private/var
Normally the /System and /sbin directory have these permissions:
drwxr-xr-x@ 4 root wheel restricted 136 Jan 23 23:35 System
drwxr-xr-x@ 59 root wheel restricted,hidden 2006 Jan 23 23:34 sbin
dirty things the bypass
Now I can do things that I am not supposed to be able to do with SIP:
mbp5:~ ladmin$ sudo touch /sbin/MyDirtyCommand.sh
mbp5:~ ladmin$ ls -l /sbin/My*
-rw-r--r-- 1 root wheel 0 Jan 26 04:34 /sbin/MyDirtyCommand.sh
Now we have demo’s how to add an empty file to the /sbin/ directory, but if I can do this, I can add anything to the /sbin/ folder. That is something a serious attacker would like to do, and that is why Apple created SIP in the first place.
Can you use this for your workflows?
The question mark after the title is because it is supposed to be checked and repaired with updates, but the 10.11.3 combo update (and 10.11.1 and 10.11.2 too) leaves the edits to the permissions of the /sbin/ and /System/ above un-repaired.
SIP is a good thing, and here to stay, so first of all you should urge the software vendor to update their software to be SIP compatible.
If that is not available (yet) you can try the bypass shown here.
The workaround I show here requires that (at least once) the client must be booted from an other (network)disk, and filevault should be off for existing systems.
The workaround shown here is best to integrate into the first (thin) imaging step.
You can create a DeployStudio workflow that only runs this script, but for FileVault users have to unlock their disk first (using Disk Utility, or the message on screen), not so easy to explain to users, and even more difficult to automate.
Some will rather install software from a NetInstall set (you can at that point) but that would not work with self-service strategy (Munki, Jamf).
Expect next OS X or security updates to ‘repair’ permissions to SIP default!
While doing some tests I learned a few things:
-Don’t run chmod -R 777 /System/ It will leave your Mac not bootable.
-do not copy a edited copy of rootless.conf file to /System/Library/Sandbox/. Same as above.
-If you want to ‘repair’ permissions, it is possible from both the recovery partition as from DeployStudio Runtime using this command:
sudo /usr/libexec/repair_packages --repair --standard-pkgs --volume /Volumes/Macintosh\ HD
-Creating an .dmg file of a system with tweaked permissions and deploying this image to other Macs using DeployStudio will leave the tweaked permissions as they are.
-the command csrutil netboot list is not needed, this info is displayed by csrutil status.
It is clear to everyone all software should be updated to support OS X 10.11 including SIP (it usually only needs to install into different directories), but if you do not write the software you have no control over that part, so as an admin you have to live with workarounds.
There is the option to turn off SIP with the csrutil disable command, but since SIP will revert to the ON status when a user clears the NVRAM this is not a good workaround.
I have no good example of software that requires ‘tweaked’ permissions to OS X, but love to hear from you if this page can help you supporting this software on El Capitan.
So is SIP not as secure as it seems? No, it is very secure addition to OS X. Bypassing SIP requires an second boot disk and knowledge of command line. SIP is designed to prevent the accidental (home and managed) admin user from making insecure changes the System (i.e. the current boot partition).
If you boot another volume, this could potentially (re)install any software, so it is normal that SIP only can protect the booted system volume.
The bypass detailed here could enable you to distribute non-SIP compatible software using self-service tools, while SIP is enabled, but bypassed for specific folders.
Learn more @ LAI
Curious to learn how to do this kind of things in your organisation?