OS X, like any other variety of Unix and most other operating systems, limits access to files and folders by means of permissions, which set out what each user can do. In theory, that should be all which is required: if a file or folder can only be modified by the ‘root’ superuser, then it should be well protected.

Like most theoretical concepts, when that spins out into practice, it doesn’t quite work that way. For those developing malware, once they can convince OS X that they have root privileges, they can modify key system folders and files. As quite a lot of security vulnerabilities result in such ‘privilege escalation’, the existing permissions system was clearly no security against malware.

So in El Capitan, Apple has implemented another layer of protection on top of ordinary permissions: System Integrity Protection or SIP. This means that even if a process manages to obtain the privileges of the root user, there are several important things which it still cannot do. These fall into three areas:

• make changes to specific folders and files,
• change, or install, kernel extensions (KEXTs),
• make certain system calls.

This article looks at the protection provided by SIP to folders and files; the next article considers its controls on KEXTs and system calls.

Settings files

There are two files that determine which files and folders are protected by SIP, at /System/Library/Sandbox/rootless.conf and /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Of these two, rootless.conf is the more important and all embracing, and paths lists some additional exceptions. Interestingly neither file has changed since SIP was first introduced, suggesting that Apple considers that it got both right first time. As these files are in /System/Library/Sandbox, they are themselves protected by SIP, which should prevent third-parties from tampering with them.

Main protected folders

The visible top-level folder which is most fully protected is /System, which contains the single folder Library, into which most OS X system-level components are installed. rootless.conf makes specific exceptions to that for some folders, including /System/Library/Caches, /System/Library/CoreServices, and /System/Library/Extensions.

Also protected are the hidden folders /bin, /sbin, and most of /usr. However /usr/local, /usr/libexec/cups (for CUPS printer support), and /usr/share/man (for man page support) are unprotected. This means that any third-party tools must be installed in /usr/local rather than in other hidden folders. The folders /private/etc, /private/tmp, and /private/var are not themselves protected, but the symlinks to them are. When SIP protects a symlink, that does not mean that the path that it links to is also protected, just the symlink itself.

Protected apps

rootless.conf also extends protection to many of the standard apps which come bundled with El Capitan, including App Store, Automator, Calendar, Chess, Contacts, Dashboard, FaceTime, Font Book, Mail, Maps, Messages, Photos, Preview, QuickTime Player, Safari, Text Edit, Time Machine, and more, and those in the /Applications/Utilities folder. Even if you do not use one or more apps from the protected list, you cannot remove them from your Mac.

Other protected files

/Library/Preferences/SystemConfiguration/com.apple.Boot.plist is explicitly protected, which may prevent you from tweaking it to allow a Mac which had an optical drive to use the Apple USB SuperDrive.

Various Apple and third-party apps still need to access locations in protected folders. The file /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths lists those exceptions, including a long list of tools which must still be installed in /usr/bin. If you want to see what they are, make a copy of /System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths and open that copy (from, say, Documents) using a text editor.

How to tell if a file or folder is being protected by SIP

Currently, the Finder’s Get Info dialog does not reveal whether something is being protected. The only way to find out is to open Terminal, and use the O (capital O) option to the shell command ls, which shows the tag restricted for items protected by SIP. For example,

Howards-iMac:~ hoakley$ ls -laO /System
total 0
drwxr-xr-x@ 4 root wheel restricted 136 21 Mar 22:11 .
drwxr-xr-x 33 root wheel - 1190 30 Apr 22:28 ..
-rw-r--r-- 1 root wheel restricted 0 23 Aug 2015 .localized
drwxr-xr-x 79 root wheel restricted 2686 20 Apr 08:41 Library

User impact

For the great majority of users, these effects of SIP pass unnoticed. For a significant minority, particularly those installing command line tools and packages, they can be show-stoppers. Those tools should have options to install them in /usr/local instead of their default path, but that doesn’t always hold.

There are only two ways that software can make changes to files or folders which are protected by SIP: in Recovery mode, and by using an installer package which is signed using Apple’s own security certificate (which is reserved for Apple’s own use – no other certificate will do). Attempts to exploit this protection are therefore likely to focus on:

• any vulnerabilities within SIP itself,
• methods of restarting in Recovery mode and installing from there,
• abusing Apple’s security certificate.

The next article will look at other protection provided by SIP, and consider whether OS X really is ‘rootless’.

References

StackExchange discussion
Rich Trouton’s account
Apple developer docs.