Home > Mac administration, Mac OS X, System Integrity Protection > System Integrity Protection – Adding another layer to Apple’s security model

System Integrity Protection – Adding another layer to Apple’s security model

As part of the release of OS X El Capitan, Apple has added a new layer named System Integrity Protection (SIP) to its security model. To understand how System Integrity Protection fits in, let’s first take a look at Apple’s security model as it existed as of OS X Yosemite.

OS X Defenses



Gatekeeper is one of the outer lines of defense. It allows users to restrict which sources they can install applications from, with the general idea being that malware will not be from an allowed source.



OS X also uses sandboxing extensively. A sandbox typically provides a tightly controlled set of resources for programs to run in. Network access, the ability to inspect the host system, or reading from input devices is usually disallowed or heavily restricted.


POSIX permissions

OS X uses the Unix permissions model as defined by POSIX, which governs which users and groups can access which files and directories. If a particular user account requests access to a particular file or directory and does not have the necessary rights, that account is refused access.



The innermost layer of defense are keychains. Keychains are very specialized databases which are designed for the storing of secrets, like passwords, private keys, PIN numbers, and then controlling access to those secrets. To help protect these secrets, keychains are encrypted.


There’s an issue with this model though and it’s been there for decades. It pre-exists OS X and even pre-exists Apple as a company. That issue is found in the POSIX permissions layer.

OS X defenses with POSIX highlighted


Whoami root


Root is the superuser for a Unix system and the Unix permissions model is designed around the assumption that root has access to everything. Apple has not ignored this issue and has put some controls in place to limit the actual root user. These controls include disabling the root user account, discouraging its use, and providing ways to access elevated or root privileges using other means.

However, the root user account is still present and still can do anything on the system.


System Integrity Protection

To limit what the superuser can do and add another layer to OS X’s security model, Apple has developed SIP and deployed it as part of OS X El Capitan. SIP is designed to limit the power of root and to protect the system even from the superuser. For more details, see below the jump.

SIP is an overall security policy with the goal of preventing system files and processes from being modified by third parties. To achieve this, it has the following concepts:

  • File system protection
  • Runtime protection
  • Kernel extension protection

File system protection

SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:

  • /bin
  • /sbin
  • /usr
  • /System

Apple has indicated that the following directories are available for developers to access:

  • /usr/local
  • /Applications
  • /Library
  • ~/Library

All directories in /usr except for /usr/local are protected by SIP.

It is possible to add, remove or change SIP-protected files and directories via an installer package which is signed by Apple’s own certificate authority. This allows Apple to make changes to SIP-protected parts of the OS without needing to change the existing SIP protections.

Sip disabling apple installer certificate

The certificate authority in question is reserved by Apple for their own use; Developer ID-signed installer packages are not able to alter SIP-protected files or directories.

To define which directories are protected, Apple has currently defined two configuration files on the filesystem. The primary one is found at the location below:


The rootless.conf file lists all the applications and the top-level of directories which SIP is protecting.

Full rootless conf


SIP is protecting the core apps which OS X installs into /Applications and /Applications/Utilities.

Rootless applications

Rootless applications utilties

This means it will no longer be possible to delete the applications which OS X installs, even from the command line when using root privileges.



SIP is also protecting a number of directories and symlinks outside of /Applications and the top level of those directories are also listed in the rootless.conf file. In addition to protections, Apple has also defined some exceptions to SIP’s protection in the rootless.conf file, and those exceptions are marked with asterixes. These exemptions from SIP’s protection mean that it is possible to add, remove or change files and directories within those locations.

Rootless exceptions

Among those exceptions are the following:

/System/Library/User Template – where OS X stores the template directories it uses when creating home folders for new accounts.
/usr/libexec/cups – where OS X stores printer configuration information

When I’ve spoken with Apple engineers about how this configuration file was updated and if third parties could add their own exceptions to it, it was made clear that Apple considers this file theirs and that any third parties’ changes to it would be overwritten by Apple.

To see which files have been protected by SIP, use the ls command with the capital O flag in Terminal:

ls -O

SIP-protected files will be labeled as restricted.

SIP protected root level directories

One important think to know is that even if a symlink is protected by SIP, that does not necessarily mean that the directory they’re linking to is being protected by SIP. At the root level of an OS X El Capitan boot drive, there are several SIP-protected symlinks pointing to directories stored inside the root-level directory named private.

However, when the contents of the directory named private are examined, the directories which those symlinks point to are not protected by SIP and both they and their contents can be moved, edited or changed by processes using root privileges.

Non SIP protected directories inside the private directory


In addition to the list of SIP exceptions which Apple has set in rootless.conf, there is a second list of SIP exceptions. This list includes a number of directories and application names for third-party products. Similar to rootless.conf, this exclusion list is Apple’s and any third parties’ changes to it will be overwritten by Apple.


Runtime protection

SIP’s protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.

  • task_for_pid() / processor_set_tasks() fail with EPERM
  • Mach special ports are reset on exec(2)
  • dyld environment variables are ignored
  • DTrace probes unavailable

However, SIP does not block inspection by the developer of their own applications while they’re being developed. Xcode’s tools will continue to allow apps to be inspected and debugged during the development process.

For more details on this, I recommend taking a look at Apple’s developer documentation for SIP.

Kernel extension protection

SIP blocks installation of unsigned kernel extensions. In order to install a kernel extension on OS X El Capitan with SIP enabled, a kernel extension must:

  1. Be signed with a Developer ID for Signing Kexts certificate
  2. Install into /Library/Extensions

If installing an unsigned kernel extension, SIP will need to be disabled first.

Managing SIP

To help ensure that third parties will not be able to disable these protections, SIP’s configuration is stored in NVRAM rather than in the file system itself and is only configurable if the Mac is booted into one of two environments:

Note: The OS X Installer and OS X Recovery environments are in fact the same environment from OS X’s perspective, with the main difference being that the OS X Installer environment contains a copy of the installation files for OS X and the Recovery environment does not.

Because SIP’s configuration is stored in NVRAM, SIP’s protection settings will apply to the entire machine and will persist even if the OS is reinstalled.

SIP can be managed to the extent of turning it on, turning it off, adding and removing IP addresses into a NetBoot whitelist and reporting on whether SIP is enabled or disabled. All changes to SIP’s configuration also require a reboot before they take effect.

The tool used to manage SIP is /usr/bin/csrutil. csrutil is able to work with SIP because it has a unique application entitlement assigned to it by Apple. This entitlement is viewable using the codesign command shown below:

codesign -d --entitlements - /usr/bin/csrutil

Csrutil application entitlement highlighted


When you run csrutil without any associated commands, it will pull up the help page.

Csrutil help


When booted from Recovery, the command used to enable SIP is csrutil enable:

csrutil enable

csrutil enable run inside Recovery

When booted from Recovery, the command used to turn SIP off is csrutil disable:

csrutil disable

csrutil disable run inside Recovery

When booted from Recovery, the command used to reset SIP’s configuration is csrutil clear:

csrutil clear

csrutil clear run inside Recovery

When csrutil clear is run, SIP goes back to its factory-default settings. That means SIP is enabled if it was disabled previously and any custom configuration is cleared out.


SIP and NetBoot

One of the custom configuration options available in SIP is the ability to set a whitelist for approved NetBoot servers. This whitelist is needed because the bless command in El Capitan is restricted by SIP from writing to NVRAM. This affects bless‘s ability to set Macs to boot from NetBoot sets because it needs to write that information to NVRAM.

This whitelist defines by IP address which NetBoot servers are trusted in your environment. Once those IP addresses are part of the whitelist, the bless command can set a Mac to NetBoot from a NetBoot set on a trusted NetBoot server. For more information about whether or not you need to whitelist your NetBoot server(s), please see the link below:


To help folks who need to use bless to set a NetBoot set as a startup drive, the csrutil tool includes functionality to add NetBoot servers to the whitelist. While booted from Recovery, use csrutil netboot add followed by an IP address to set the IP as being that of a NetBoot server approved for use by the bless command:

csrutil netboot add ip.address.here

Csrutil netboot add run inside recovery


While booted from Recovery, you can also remove NetBoot servers from the whitelist. To do this, use csrutil netboot remove followed by the IP address that you want to remove from the whitelist.

csrutil netboot remove ip.address.here

Csrutil netboot remove run inside recovery


To see which NetBoot servers have been added to the whitelist, run csrutil netboot list.

csrutil netboot list

Csrutil netboot list run inside recovery



Running csrutil outside Recovery

If you try to run the csrutil enable and csrutil disable commands while booted from a regular boot drive, you will receive a message that these commands need to be run from Recovery. The current SIP configuration will remain unchanged.

Csrutil enable run outside recovery

Csrutil disable run outside recovery


Likewise, if you try to run the csrutil netboot add and csrutil netboot remove commands while booted from a regular boot drive, you will receive the message that csrutil was unable to save the configuration and the status of the NetBoot whitelist will remain unchanged.

Csrutil netboot add run outside recovery

Csrutil netboot remove run outside recovery


What can be run while booted from a regular boot drive is csrutil’s reporting functions. For example, to learn if SIP is enabled or disabled, run csrutil status.

csrutil status

Csrutil status

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

If SIP is off, 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.

Csrutil status disabled run outside recovery


I actually have a bug report on this message. For those who wish to dupe it, it is bug ID 22361698 and is cross-posted to Open Radar here:



Likewise, you can run csrutil netboot list and it will report on which IPs have been set as allowed NetBoot sources when using the bless command.

Csrutil netboot list run outside recovery


Other custom SIP configuration options

It is also possible to enable SIP protections and selectively disable aspects of it, by adding one or more flags to the csrutil enable command. All require being booted from Recovery in order to set them:

Enable SIP and allow installation of unsigned kernel extensions

csrutil enable --without kext

Csrutil enable kext disabled run inside recovery


When this option is enabled, running csrutil status should produce output similar to this.

Csrutil status enabled kext disabled run outside recovery


Enable SIP and disable filesystem protections

csrutil enable --without fs

Csrutil enable fs disabled run inside recovery


When this option is enabled, running csrutil status should produce output similar to this.

Csrutil status enabled fs disabled run outside recovery

Enable SIP and disable debugging restrictions

csrutil enable --without debug

Csrutil enable debug disabled run inside recovery

When this option is enabled, running csrutil status should produce output similar to this.

Csrutil status enabled debug disabled run outside recovery

Enable SIP and disable DTrace restrictions

csrutil enable --without dtrace

Csrutil enable dtrace disabled run inside recovery

When this option is enabled, running csrutil status should produce output similar to this.

Csrutil status enabled dtrace disabled run outside recovery

Enable SIP and disable restrictions on writing to NVRAM

csrutil enable --without nvram

Csrutil enable nvram disabled run inside recovery

When this option is enabled, running csrutil status should produce output similar to this.

Csrutil status enabled nvram disabled run outside recovery


SIP is a big change, but I think it should also be considered a work in progress. I’m expecting to see additional changes to SIP’s functionality in both El Capitan and future releases of OS X, as Apple sees how SIP works in the real world.


  1. Stephan
    October 2, 2015 at 3:50 pm

    Rich, thanks again for another informative article! Lots of great info here!

  2. October 2, 2015 at 11:19 pm

    Hi Rich,

    first thanks for your article.

    Apple talks at the end of this documentation about a special option for enterprise environments:


    “Note: For certain enterprise configurations that do not allow booting to Recovery OS, System Integrity Protection can be configured by other means.”

    As far as I know, the option which worked in the first beta releases of 10.11 was:

    sudo nvram boot-args=”rootless=0″; osascript -e ‘tell app “loginwindow” to «event aevtrrst»’

    Might it be possible to use this also in the final release of 10.11 now, if we disable the restrictions to write to nvram?

    csrutil enable –without nvram

    Would be great to know. Or does Apple offer other options for the enterprise we don’t know yet?

  3. October 6, 2015 at 7:09 pm

    Rich – Please let me know if you’d like different attribution or verbiage to the link from http://apple.blogoverflow.com/2015/10/el-capitan-resources/

    • October 6, 2015 at 7:11 pm

      That looks great, thanks!

  4. October 7, 2015 at 8:47 am

    Great post. Thanks for the useful and complete explanation!

  5. November 20, 2015 at 12:42 pm

    Any workarounds for your Firstboot script that modifies the loginwindow.plist ?

  6. Daniel Wisehart
    March 13, 2016 at 10:00 pm

    Thanks for a great article. Even after disabling SIP, certain things do not work. The DTruss man page still (El Capitan 10.11.3) lists the example ‘dtruss df -h’ but entering that as root gives:
    dtrace: failed to execute df: dtrace cannot control executables signed with restricted entitlements

    The workaround–at least for now–is that files in the /bin directory are restricted, not the df command itself. So, as root:
    cp /bin/df /tmp
    dtruss /tmp/df -h
    works just fine.

  7. johnmsawyer
    April 13, 2016 at 8:34 pm

    Good thorough article.

    I’d note that since the SIP protection setting is stored in NVRAM, that it can be changed from disabled to enabled by resetting the Mac’s PRAM/NVRAM, by rebooting or powering up the Mac, and then before the screen lights up, holding down Command-Option-P-R until you hear a startup chime after the initial powerup or startup chime. Normally, resetting NVRAM requires you to shut down the Mac, and then to hold down the key combo until you hear two startup chimes after the initial powerup chime, but I found (at least on several Macbooks) that all that’s required to re-enable SIP is to restart the Mac (no need to shut down), and then to hold down the key combo until you hear just one more chime.

  8. Brett
    April 15, 2016 at 10:16 pm

    I am not a sys admin. I am a musician with a little bit of un*x knowledge. in order to make my macbook pro system work the way I want, I moved the /Library/Audio folder to a second internal drive. I then symlinked /Library/Audio to it. This worked great under 10.10. Then I upgraded to 10.11 and now I am having problems with one software product that writes an audio driver into Plugins/HAL. They told me that the problem is because of “apple’s new security feature”. They won’t help me. Everything else on my system works find under 10.11.

    Using SIP is there a way to turn off SIP for this path so the system can get at the driver? or…?

    thanks for your help!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: