Automatic Disabling SIP with El Capitan Upgrade

Automatic Disabling SIP with El Capitan Upgrade

Screen Shot 2016-07-29 at 5.15.07 PMOverview

System Integrity Protection or “SIP” is a new security measure implemented in 10.11 “El Capitan”. SIP protects access to system locations and restricting runtime attachment to system processes, this security policy guards against compromise — whether accidental or by malicious code. SIP protects file system locations that we are managing with our current client management system called Radmind. Radmind operates as a tripwire with the ability to detect any modifications to the file system and reverse those changes to a known state.

System Integrity Protection

To protect the integrity of OS X, Apple added SIP to 10.11 “El Capitan” to increase security by limiting the root user’s power, requiring siging, special system entitlements, etc. When SIP is fully enabled it:

  • Restricts file system modifications to some directories
  • Kernel extensions must be signed with Developer ID
  • Runtime protection with special system entitlements
  • Command line startup disk selection commands like Bless
  • Limits setting & modification of NVRAM variables

OS_X_security_layers.svg

The rootless configuration, Rootless.conf contains the list of all the files that the system prevents from being modified. The file can be found in:

/System/Library/Sandbox/rootless.conf

You can see what files are protected by using the ls -alO command. When you look at the output in the metadata it will say that the file is restricted. Screen Shot 2016-08-01 at 10.34.18 PMThere is an additional file like the Rootless.conf file but for 3rd party applications located in:

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Any changes to these exception files will be overwritten by Apple.

System Integrity Protection restricts file modifications to specific locations it conflicts with our our current management system. This is a great feature in OS X “El Capitan” that adds additional system protection, but in our environment it restricts area’s of the file system that we manage with radmind, which runs as a tripwire to catch any suspicious files and replace them. SIP breaks our current management system and we needed to deploy “El Capitan” for our computer rollout. We decided to temporarily turn SIP off on all of our computers until we migrate over completely to JAMF’s Casper Suite.

There are multiple methods to configure or disable SIP like booting to the Recovery Drive, NetBoot, or the OS X Installer when upgrading your computer to OS X El Capitan. One method to configure or disable SIP, is to boot to the recovery partition and use the csrutil command. By using csrutil’s disable flag, it will completely disable all features of SIP. If you don’t want to disable all features of the SIP you can use one of the below options:

  • To disable only File System Protection
    • csrutil enable –without f
  • To disable only Debugging Protection
    •  csrutil enable –without debug
  • To disable only DTrace Protection
    • csrutil enable –without dtrace
  • To disable only NVRAM Protection
    •  csrutil enable –without nvram
  • To disable only Kernel Extension Protection
    •  csrutil enable –without kext
Screen Shot 2016-08-02 at 1.19.52 PM

“csrutil enable –without fs” was used before the status was checked.

Note: These commands are unsupported configurations and might break or not be available in future macOS Updates.

Disabling SIP or a specific SIP feature might be useful as a short-term work around an issue or needed functionality, but since it adds many system protection features and will be advanced with future macOS releases, I wouldn’t recommend turning it off for the long-term. I suggest you contact and give pressure to vendors that require SIP to be disabled to fix their software. We will be turning SIP back on when we are completely migrate off radmind, and since radmind is open source and no longer being maintained, we couldn’t contact or put pressure on the vendor.

Recovery Partition Modification

The Recovery Partition is a disk image (dmg) that is stored in the Recovery HD partition on the main hard drive or in the OS X Installer Package. The BaseSystem.dmg is the disk image that the Recovery Partition uses to boot the system. For the Recovery HD, BaseSystem.dmg can be found in the com.apple.recovery.boot folder. For the OS X Installer, it can be found in the Contents/SharedSupport/InstallerESD.dmg in the Installer Package. The disk image mounts as read-only. To customize the Recovery Partition to disable SIP during installation or each time you boot from the Recovery Partition follow these steps:

  1. Make a copy of the original disk image
  2. Convert the disk image to a read/write disk image using Disk Utility.
  3. Add the SIP Disable script to /usr/local/binGitHub Page
  4. Add the Launch Daemons Property List. GitHub Page
  5. Remove Safari to make room for the script.
  6. Compress the disk image back to a read-only image.
  7. Replace the original disk image with the modified one.

You can use these above steps to add whatever customization, like an application or administrative tool to the recovery partition. However, the recovery partition is a specific disk quota and you could get an error like this if your modifications don’t leave enough disk space. Error (async): The new recovery partition would be too large (-69668)

OS X InstallerScreen Shot 2016-08-02 at 12.42.46 PM

OS X Installer contains a Recovery Partition to install the OS, we could use the modified Recovery Partition to turn SIP off during the installation process? Yes, but not by directly modifying the OS X “El Capitain” installer package, the installer package checksums InstallESD.dmg disk image and a modified version fails the checksum resulting in the installer erring out. To use the modified Recovery Partition you have to let the installer first put down all the files it needs to complete the installation. To get the files that it requires, first download the latest version of the installer. Start the installer and allow it to install up to the point where it wants you to restart the computer. At this point quit or force quit the installer. On the root of the volume you were installing on there will be a folder called ./OS X Install Data/ . There you will find all the components listed below.

The installer installs the following components:

  • ./OS X Install Data/InstallESD.dmg

    • Contains the DMG for the Recovery Partition.
  • .IAProductInfo
    • Uses the Volume UUID to know where the installer is at.
  • /OS X Install Data/OSInstallAttr.plist
    • Allows the automation to start off, will go stale after a few hours.
  • /OS X Install Data/minstallconfig.xml
    • Uses the Volume UUID to know which hard drive to mount to.

Pasted image at 2016_08_01 12_24 PMThe installer uses the bless command to boot to the recovery partition. Drives without Core Storage or File Vault use the following bless command:

bless -setBoot -folder “/OS X Install Data” -bootefi “/OS X Install Data/boot.efi” -options config=”\OS X Install Data\com.apple.boot” -label “OS X Installer”‘

To automate the upgrade process on all the system. I modified the installospkg_postflight script, originally for Munki, that changes all the values for a particular system in the installer components then uses the bless command to boot to the Recovery Partition. Note, the bless command works differently for Core Storage Volumes. Core Storage Volumes need a boot helper for it to load up properly. When running the installation you need to create the helper by copying the following files:

  •  System/Library/CoreServices/PlatformSupport.plist
  •  System/Library/CoreServices/SystemVersion.plist
  •  usr/standalone/i386/EfiLoginUI

into ./OS X Install Data/ then use the bless command to boot to the directory.

Once the computer boots into the recovery partition, the SIP disable script will launch and disable SIP on the computer. Then the installer will take over at this point to upgrade your system. When complete the computer will be completely upgraded and have SIP disabled.

Conclusion

SIP can be pain to manage but it keeps the system safe from malicious or accidental issues. Modifying the Recovery Partition is one way to handle turning SIP off if you need too. I wouldn’t recommend disabling SIP unless you absolutely have too. We needed to due to our backend system completely breaking with SIP on. If you would like to know more about SIP and modification recovery drives, here are some resources that you can check out:

2 Comments
  • S. Byrnes - BMRT
    Posted at 17:41h, 08 March Reply

    This was thoroughly discussed. Thank you so much! Quick question: has this issue been addressed in the Sierra update or do we still have to set things up manually?

    • Richard Glaser
      Posted at 18:38h, 08 March Reply

      Sorry, can you give more details? What issue are you wondering about? If it has addressed in macOS Sierra update? With MalewareBytes or OS update like Xprotect or in reference to a specific malware or exploit?

Leave a Reply