os x el capitan

El Capitan: System Integrity Protection

Over the years, Apple has added some great security layers to OS X to help make using a Mac more secure. These have included FileVault, App Sandboxing and Gatekeeper.

In El Capitan, Apple are adding a new layer of security called System Integrity Protection. This new layer of security is designed to protect the integrity of the system itself.

As with all traditional Unix systems, the root account is all empowering. It can practically do anything it wants including removing or replacing key system files.

With Mac systems, a typical setup would be a single user who is also an admin on that computer, which means you are one step away from granting someone root access to the system.

How many times are you prompted for your password when an App wants to make a change or perform an install? Most users blindly just enter their password. Once the password is entered, that app would not have too much trouble getting root access to the system and thus could perform any untold amount of damage.

This is where System Integrity Protection comes into play. In a nutshell, it prevents key system directories from being modified even by the root account. This is why this feature is sometimes known as “Root Less”. So even if a process was granted root access, it could not modify or delete certain directories within key parts of the file system.

So as an example, the following directories would be protected. /System, /bin, /usr.

This command would now fail in El Capitan:  sudo touch /usr/test

For most users, they will not be aware that this service is in play. Apple code is exempt so installations from the Mac App Store or system updates would not be affected.

For some more advanced users, this potentially could cause some issues.

As an example, if you install homebrew services or have custom bespoke services installed, then potentially they could live in /usr, which is now out of bounds in El Capitan. Therefore, when you upgrade to El Capitan, a migration will be performed, moving these items to directories that are allowed, which could break some solutions.

In the case of the /usr directory, /usr/local is still allowed for this sort of circumstance.

This feature can be disabled by booting to the Recovery OS and running a new Security Configuration utility to disable it. Beware that this actually sets a parameter in NVRAM, so it’s persistent between OS’s on that box.

security config el capitan

Overall though, this is a nice addition to OS X.



9 Replies to "El Capitan: System Integrity Protection"

  • George

    “Apple code is exempt so installations from the Mac App Store..” By installations are you speaking of only system software or also apps? If apps, would these new security layers not actually mitigate the issues security researchers from Indiana University discovered regarding cross-app resource attacks?

  • I see clamXav and Sophos use the /usr folder. So while System Integrity Protection seems like a good idea, it’s going to be harder to play well with other worthwhile protections.

  • Angus

    Hi. I was under the impression that this information couldn’t be discussed in a publicly accessible site due to the Apple NDA.

  • Andrew McNaughton

    Just needed to switch this off… Looks like they’ve changed this like they did with Password Reset in the past. Found this publicly:

    The supported way to disable System Integrity Protection in those cases where it’s truly necessary is to boot into the Recovery partition and turn System Integrity Protection off from there with the csrutil tool.

    $ csrutil
    usage: csrutil
    Modify the System Integrity Protection configuration. All configuration changes apply to the entire machine.
    Available commands:
    Disable the protection on the machine. Requires a reboot.
    Enable the protection on the machine. Requires a reboot.
    Display the current configuration.

    The kext-dev-mode and rootless boot-args are being removed from OS X El Capitan and will no longer work.

Leave a Reply

Your email address will not be published. Required fields are marked *