In the Unix model of life, there is one superuser: root. Gain root access to a Unix system, and you own it; you are at the top of the tree of permissions and privileges.

Since it was introduced in OS X 10.11 El Capitan, and even more so in Sierra, Apple has changed that model by implementing another level above root – this is System Integrity Protection (SIP). This is why you now cannot trash the apps that Apple bundles in macOS, not even Text Edit. It’s also why you can’t tamper with files or folders in /System/Library, and why some old third-party extensions and customisation tools no longer work.

The idea is, as usual, simple. On a normal Unix system, malware or an intruder which gains root access has free reign to wreak havoc. They can replace system files and take the whole system over. The only protection standing between such attacks and the system is a password which will allow them to escalate privileges to become root. SIP protects almost all the system files and folders in macOS, by locking even the root user from tampering with them.

SIP is more complex. In addition to blocking anyone from making changes to the files and folders which it protects, it also imposes strict limits on kernel extensions (KEXTs), and on certain internal macOS system calls.

Protected items

Information about the files and folders which are protected by SIP is stored in three files, inside /System/Library/Sandbox:

• com.apple.xpc.launchd.rootless.plist is a list of the system’s removable services, such as fingerd, named as com.apple.fingerd.
• rootless.conf is the main list of protected folders and apps.
• Compatibility.bundle/Contents/Resources/paths lists some exceptions to SIP such as gutenprint, which are still tolerated for compatibility.

There are two reliable ways of discovering whether a file or folder comes within SIP’s protection. You can look it up in rootless.conf, or you can list it in Terminal using
ls -laO
which returns entries like
drwxr-xr-x@ 4 root wheel restricted 136 27 Mar 20:01 System
drwxr-xr-x@ 38 root wheel restricted,hidden 1292 27 Mar 20:01 bin
where ‘restricted’ means that they are protected by SIP.

Where rootless.conf lists a folder with a space as the first character on that line, that folder is protected; if there is a non-space character at the start of the line, then that location is not protected.

For example, although almost everything in /System is protected by SIP, an exception is made for /System/Library/Caches, which is widely used to write cache files. The major hidden folders /bin, /sbin, and /usr are protected, but a key area within those which is unprotected is /usr/local, which is where user-installed tools must now be kept.

If you try running old or non-macOS installers, you may well find that they fail because they try to write tools or scripts to protected folders. It is often very laborious to modify them to work properly, and you will be best off finding a version ported to work on recent versions of macOS with SIP, or use one of the package and installation management systems for Sierra.

Outside /System, SIP protection is more patchy. It includes all the bundled apps which are part of macOS, even Chess.app, which prevents you from restoring them from a backup, or removing unwanted apps to free up disk space.

One file which is explicitly protected is /Library/Preferences/SystemConfiguration/com.apple.Boot.plist. Although users don’t normally want to edit that, it has been a way of enabling certain models of Mac to use an Apple USB SuperDrive. That trick no longer works.

Kernel extensions

When your Mac starts up, it loads various modules which extend its capabilities to do all the things that it needs to, particularly to use your Mac’s hardware such as its Ethernet networking port. These modules work low-down, close to the macOS kernel, and have always been an Achilles heel. Not only were they a good means for malware to attack a Mac, but old and buggy kernel extensions are a reliable way of bringing any Mac to its knees.

SIP requires that kernel extensions are signed using a special developer signature, and checks kernel extensions against a blacklist which is stored in the kernel extension /System/Library/Extensions/AppleKextExcludeList.kext. Updates to that list are pushed out silently by Apple; at the time of writing the version for Sierra is 12.5.0. An up to date list is available here, and you can check yours using LockRattler (free from the Downloads item above).

You can check your loaded kernel extensions in the Extensions item in the Software section of System Information, and obtain extensive detail using Objective-See’s KextViewr tool (free).

Runtime protection

To the normal Mac user, these security measures should not be noticed at all, but for a small number they have caused major problems.

Some specialist system calls, task_for_pid() and processor_set_tasks(), now fail; the exec(2) call resets Mach special ports; the dynamic link editor dyld ignores environment variables when launching protected processes; DTrace probes and other means of attaching to system processes are not available; and writing to NVRAM is restricted. If none of that means anything to you, it means that you should not be affected by this part of SIP.

Controlling SIP

There are only three ways of gaining control of SIP: one is to be Apple, whose special installer signatures can function as a super-superuser; the second is to restart in Recovery mode, enter Terminal there, and use csrutil; the third is to mount that volume as a non-boot volume, as SIP only protects the startup volume which is mounted on /, not those in /Volumes.

When running normally, you can only show SIP’s status, using
csrutil status
or configure allowed NetBoot sources, using
csrutil netboot

macOS Sierra 10.12.2 added a new command
sudo csrutil clear
which requires you to authenticate using your admin user’s password, and should enable SIP without your having to enter Recovery mode. Be careful, though, to check that it works properly, if you try using it.

In Recovery mode, you can use three additional commands:
csrutil enable
which enables SIP,
csrutil disable
which disables SIP, and
csrutil clear
which clears the existing configuration.

You can also enable parts of SIP when in Recovery mode: csrutil enable allows the following options:

• --without kext : without Apple internal and KEXT signing protection
• --without fs : without Apple internal and file system protection
• --without debug : without Apple internal and debugging protection
• --without dtrace : without Apple internal and DTrace protection
• --without nvram : without Apple internal and NVRAM protection.

Checking SIP

Late in 2016, many brand new MacBook Pro 2016 models shipped with SIP turned off. As this is not the sort of thing which normal users check, most of those were used for some weeks without the protection of SIP. I recommend that one of the first things that you do when you have set a new Mac up is to check whether SIP is turned on.

The easiest way is to open System Information, and click on Software at the left. This will include a clear statement that SIP is turned on, or off.

If you want to know more, including the current versions of your Mac’s security data files, then LockRattler will provide all the detail, including whether SIP is turned on or off. It is free from the Downloads item above, and has already saved quite a few users who thought that SIP was protecting them, when it wasn’t.

Is it bulletproof?

Like any other part of macOS, SIP has had its own bugs, some of which have led to vulnerabilities. So far, there do not appear to have been any exploits of those, and those vulnerabilities which have been released to the public have been fixed. But there always remains the possibility that there are remaining vulnerabilities, which could be exploited. Like all protection, SIP will not save you if you behave recklessly, but for the moment at least is highly effective.