Since you upgraded to OS X 10.11 El Capitan, you may have noticed that some older apps crash consistently. Sometimes this is because the apps do things that they shouldn’t; sometimes it is because El Capitan wants them to, because security.

One of the lesser-known new features in El Capitan is SIP: not the side impact protection which you like in your car, but System Integrity Protection.

What does SIP do?

Gatekeeper has been present for a few years now, aiming to prevent us from running potentially malicious apps through its checking of code signatures. But Gatekeeper does nothing to protect OS X’s crucial system files. If a malicious app does somehow slip the net (think XCodeGhost, maybe), permissions are not sufficient defence to stop it from tampering with system files. Nor, for that matter, are they good enough to prevent inadvertent changes being made.

SIP is intended to stop apps which are not supplied through the App Store from the following:

• modifying system files, which can now only be modified by apps signed by Apple,
• runtime attachment to system binaries, which can only be modified by Apple,
• kernel extensions (KEXTs) must be specially signed.

These do not apply to App Store apps, because they can only run in a sandbox which already prevents them from any of those behaviours.

System-only locations which are now forbidden include the hidden top-level folders /bin, /sbin, /usr (except for /usr/local), and the visible /System folder. Instead you should use folders such as /usr/local, /Applications, and /Library, which are still protected by permissions, but not by SIP. There are also reports that SIP protects certain Apple-installed apps in /Applications and elsewhere, but this is not mentioned in Apple’s documentation.

When you first installed El Capitan, any non-Apple files which it found in those forbidden places should have been moved to /Library/SystemMigration/History/Migration-[UUID]/QuarantineRoot/, where [UUID] is a unique user ID. On my Mac, a lot of those moved there turn out to be old Apple items.

SIP also explains why Disk Utility and other apps can no longer check or repair preferences: SIP maintains those for system files, and they are checked and repaired automatically when system updates are performed.

Is it running on my Mac?

SIP is by default turned on in El Capitan, and together with the rest of your security configuration persists between installs, boots, and different startup drives: it is kept in NVRAM. The only way that you can change SIP setting is by starting up in Recovery mode, entering the command shell in Terminal, and using the csrutil command (below).

You can check whether SIP is enabled (it will be) by typing the following into Terminal’s command line:
csrutil status

How do I control SIP?

The csrutil tool does not (yet) have a man page, but is the only way that you can control SIP. To read details of its commands, you should type
csrutil help

There are three options of practical use, apart from querying its status:

• csrutil enable turns SIP on, when booted in Recovery mode,
• csrutil disable turns SIP off, when booted in Recovery mode,
• csrutil netboot allows you to configure a list of allowed NetBoot sources.

If you are running Macs with configurations that do not allow booting to Recovery mode, or want to use its netboot list, then you should read Apple’s instructions.

Why not just turn if off?

So why don’t we just turn SIP off, and carry on without all this hassle? Because it is providing us with an extra level of protection which, in the current hostile threat environment, we need. If your Mac connects to the Internet or ever has external drives etc. connected, then it needs SIP.

Back in the days of Mac OS Classic, people used to open up their system files using the resource editor ResEdit, so that they could tweak the wording in some system dialogs, for example. Sadly the world has changed a great deal since then: our systems need all the protection they can get.

If you do have a crucial app which used to run fine under Yosemite but which now crashes, there is a change that it is doing so because it is hitting SIP, and once blocked, it is not handling it gracefully. If you want to try it, first make yourself a nice big sticky saying “SIP OFF” and place that in a prominent position on your Mac.

Then start up in Recovery mode (Command-R at startup). Once the system is up and running, open Terminal, type
csrutil disable
and press return. Restart normally, check SIP by opening Terminal and typing
csrutil status
then run your app. If it has stopped crashing, you at least have one way of still using it. Once happy, restart in Recovery mode, open Terminal, type
csrutil enable
then restart and check SIP with
csrutil status
If it is back on again, you can discard the SIP OFF sticky.

Is SIP the thin end of the wedge?

Finally, some have claimed that SIP is another step in the merging of OS X with iOS. That is simply untrue. We do not know whether the OSes will ever merge (I doubt it, in the foreseeable future at least). However SIP stops third parties from doing things that they never should have been doing, which have always been recognised as being dangerous as well as threats to security, and which they should have moved away from a long time ago.

One fatal flaw in the argument that OS X will become as restrictive as iOS is that developers have to develop somewhere. Any OS which provides good resources for such development – as OS X does – will also offer a lot more freedom that iOS ever will. And I cannot see Apple porting Xcode to Windows 10, can you?