Since its introduction in El Capitan, System Integrity Protection (SIP) has extended over more and more folders and files. In High Sierra, its use to manage third-party kernel extensions has already started to raise issues. Armed with my new extended attribute editor, xattred, I have been exploring what you can and cannot do with SIP turned on.

You can always, of course, turn SIP off from Recovery mode. Once you have done that, you should be able to work fairly normally within the limits of permissions. But the point of SIP is to protect our Macs, and I have known more than one user turn SIP off to do something, and forget to turn it back on.

Apps and scripts also don’t have the option of flicking a switch to control SIP. When macOS decides to protect part of an app using SIP, there is nothing that any third-party product can do about it.

The details of SIP vary across El Capitan, Sierra, and High Sierra, but there are generally two ways in which items can be marked as protected by SIP: main folders are specified in System/Library/Sandbox/rootless.conf, and individual items outside those are marked by an extended attribute of type com.apple.rootless. Files and folders which are within those are shown as being protected when listed using ls -lO in Terminal, and any attempts to move, remove, or modify them are strongly resisted by macOS.

As System/Library/Sandbox/rootless.conf is protected by SIP itself, trying to modify that is fruitless. But users do have more control over extended attributes.

Try to do anything other than view SIP xattrs, though, and you quickly run into trouble. Using the xattr tool in Terminal or xattred and any attempt to change a com.apple.rootless xattr – even to paste it into an unprotected file – brings instant failure.

That proves to be true for any file or folder on your startup volume, but is not so restricted when working with a volume other than the boot disk.

Here’s a SIP xattr on one of Apple’s bundled kernel extensions in High Sierra’s /System/Library/Extensions folder, and deeply uninteresting it looks too. Many of these xattrs are empty, suggesting that the SIP mechanism doesn’t allow any other processes to control them. Others, such as the protection applied to High Sierra’s /Library/StagedExtensions folder, nominate other processes, in that case the KernelExtensionManagement service in macOS 10.13.

You can, though, apply your own com.apple.rootless xattrs to files and folders which are not on the boot disk. Here I have copied one from a kernel extension and pasted it into a user document. This should prevent any tampering with that file, at least when a Mac has been booted from that disk.

You still don’t have complete control over SIP, at least not over files which already have a com.apple.rootless xattr. Try to edit that xattr or remove it in any way, and macOS will stop you. But notice this time that the error is not that the operation is not permitted, but that permission is denied. Of course, with SIP protecting it, you can’t change its permissions either, so the end result is the same.

On the other hand, when applied to one of my documents for which I had full permissions, I retained full control over the xattr so long as the file was on a non-boot volume. Like other xattrs, it is stored in the volume metadata, and only fully effective when booted from that volume.

Given how awkward SIP can be, and the potential pain which it can cause, it may seem crazy to want to add the com.apple.rootless xattr to any other files or folders. But at least this demonstrates that it can be done, so long as they are not on the boot disk. If you want to set or remove com.apple.rootless xattrs, you will need another bootable disk, as I am fairly sure that the command xattr is not included among the tools provided in Recovery mode.

This also emphasises that SIP offers no easy ways of circumvention. Once a file or folder is protected, that is not simple to alter, even for macOS itself.