What is the "rootless" feature in El Capitan, really?

Question

I have just learned about the "Rootless" feature in El Capitan, and I am hearing things like "There is no root user", "Nothing can modify /System" and "The world will end because we can't get root".

What is the "Rootless" feature of El Capitan at a technical level? What does it actually mean for the user experience and the developer experience? Will sudo -s still work, and, if so, how will the experience of using a shell as root change?

Answer 1

First: the name "rootless" is misleading, since there's still a root account, and you can still access it (the official name, "System Integrity Protection", is more accurate). What it really does is limit the power of the root account, so that even if you become root, you don't have full control over the system. Essentially, the idea is that it's too easy for malware to get root access (e.g. by presenting an auth dialog to the user, which will cause the user to reflexively enter the admin password). SIP adds another layer of protection, which malware can't penetrate even if it gets root. The bad part of this, of course, it that it must also apply to things you're doing intentionally. But the restrictions it places on root aren't that bad; they don't prevent most "normal" system customization.

Here's what it restricts, even from root:

• You can't modify anything in /System, /bin, /sbin, or /usr (except /usr/local); or any of the built-in apps and utilities. Only Installer and software update can modify these areas, and even they only do it when installing Apple-signed packages. But since normal OS X-style customizations go in /Library (or ~/Library, or /Applications), and unix-style customizations (e.g. Homebrew) go in /usr/local (or sometimes /etc or /opt), this shouldn't be a big deal. It also prevents block-level writes to the startup disk, so you can't bypass it that way.

  The full list of restricted directories (and exceptions like /usr/local and a few others) is in /System/Library/Sandbox/rootless.conf. Of course, this file is itself in a restricted area.

  When you upgrade to El Capitan, it moves any "unauthorized" files from restricted areas to /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• You can't attach to system processes (e.g. those running from those system locations) for things like debugging (or changing what dynamic libraries they load, or some other things). Again, not too much of a big deal; developers can still debug their own programs.

  This does block some significant things like injecting code into the built-in Apple apps (notably the Finder). It also means that dtrace-based tools for system monitoring (e.g. opensnoop) will not be able to monitor & report on many system processes.

• You can't load kernel extensions (kexts) unless they're properly signed (i.e. by Apple or an Apple-approved developer). Note that this replaces the old system for enforcing kext signing (and the old ways of bypassing it). But since v10.10.4 Apple has had a way to enable trim support for third-party SSDs, the #1 reason to use unsigned kexts has gone away.

• Starting in Sierra (10.12), some launchd configuration settings cannot be changed (for example, some launch daemons cannot be unloaded).

• Starting in Mojave (10.14), access to users' personal information (email, contacts, etc) is restricted to apps that the user has approved to access that info. This is generally considered a separate feature (called Personal Information Protection, or TCC), but it's based on SIP and disabling SIP disables it as well. See: "What and how does macOS Mojave implement to restrict applications access to personal data?"

• Starting in Catalina (10.15), protection of most system files is strengthened by storing them on a separate read-only volume. This is not strictly part of SIP, and is not disabled by disabling SIP. See: WWDC presentation on "What's New in Apple [Catalina] File Systems" and "What's /System/Volumes/Data?".

• Starting in Big Sur (11.x), the read-only system volume is now a "Sealed System Volume" (a mounted snapshot rather than a regular volume), so making changes to it is even more complicated. See: the Eclectic Light Company article "Big Sur boot volume layout".

If you don't want these restrictions -- either because you want to modify your system beyond what this allows, or because you're developing & debugging something like kexts that aren't practical under these restrictions, you can turn SIP off. Currently this requires rebooting into recovery mode and running the command csrutil disable (and you can similarly re-enable it with csrutil enable).

Modifying the system volume in Catalina requires disabling SIP, then mounting the volume with write access (and then rebooting and turning SIP back on is recommended). In Big Sur, additional steps are required to disable authentication of the system volume before changes, and afterward create a new snapshot.

You can also selectively disable parts of SIP. For example, csrutil enable --without kext will disable SIP's kernel extension restriction, but leave its other protections in place.

But please stop and think before disabling SIP, even temporarily or partially: do you really need to disable it, or is there a better (SIP-compliant) way to do what you want? Do you really need to modify something in /System/Library or /bin or whatever, or could it go in a better place like /Library or /usr/local/bin etc? SIP may "feel" constraining if you aren't used to it, and there are some legitimate reasons to disable it, but a lot of what it enforces it really just best practice anyway.

To underscore the importance of leaving as much of SIP enabled as much of the time as possible, consider the events of September 23, 2019. Google released an update to Chrome that tried to replace the symbolic link from /var to /private/var. On most systems, SIP blocked this and there were no bad effects. On systems with SIP disabled, it rendered macOS broken and unbootable. The most common reason for disabling SIP was to load unapproved (/improperly signed) kernel extensions (specifically video drivers); if they'd only disabled the kext restriction, they would not have been affected. See the official Google support thread, a superuser Q&A on it, and an Ars Technica article.

References and further info: WWDC presentation on "Security and Your Apps", a good explanation by Eldad Eilam on quora.com, the Ars Technica review of El Capitan, and an Apple support article on SIP, and a deep dive by Rich Trouton (who also posted an answer to this question).

Answer 2

For me, it means DTrace no longer works.

DTrace is similar to ptrace/strace in Linux, in that it allows you to see what a process is saying to the kernel. Every time a process wants to open a file, write a file, or open a port, etc, it needs to ask the kernel. In Linux, this monitoring process happens outside of the kernel in "userland", and thus permissions are quite fine-grained. A user can monitor their own applications (to fix bugs, find memory leaks, etc) but would need to be root to monitor another user's process.

DTrace on OSX however works at the kernel level, making it much more performant and powerful, however it requires root access to add its probes into the kernel and thus do anything. A user cannot trace their own processes without being root, but as root they can not only watch their own processes, but in fact ALL processes on the system simultaneously. For example, you can watch a file (with iosnoop) and see which process reads it. This is one of the most useful features ever for detecting malware. Because the kernel also deals with network IO, the same is true there. Wireshark detects unusual network activity, DTrace tells you the process sending the data, even if its as embedded into the system as the kernel itself.

As of El Capitan however, Apple has deliberately prevented DTrace from working - as in it has been specifically targeted and singled out as something SIP restricts. Why would they do this? Well, previously Apple modified their kernel and DTrace to allow some processes to opt-out of being monitored via DTrace (which upset a lot of security researchers at the time as some processes were now off limits even as root - include malware). Their reason for this was to protect DRM in apps like iTunes since theoretically someone could DTrace and grab un-DRM'd data out of the processes' memory.

However, there was an important work-around that allowed the researchers to keep doing their jobs, and that was to modify the kernel to ignore this opt-out flag, so DTrace could still be used on these processes. This was actually really great because programs trying to evade detection where now lit-up with this no-DTrace flag. Anything Apple or the bad guys wanted to hide was now in plain sight...

But it doesn't work now, so how does this affect you? Well, it will affect you both directly and indirectly. Directly, it will limit your ability to monitor your system. A large number of low-level system administration and monitoring tools (which higher-level tools build upon) will no longer work. The indirect effect however will be much larger - security professionals rely on deep system access to detect the worst kinds of threats. We simply cannot do that any more. It is critical when analysing malware that it doesn't know it's running in a debugger or honeypot. Disabling SIP tells all software, from both the bad guys and Apple, that this system is being watched. No more watching the watchers. If SIP was about security they could have educated users about root - instead they removed it. Ultimately this means that Apple has replaced the 'be all and end all' security barrier of the root password, with the 'be all and end all' SIP protection mechanism. Or if your any good at social engineering, a root password with a reboot...

There's also this:

Answer 3

System Integrity Protection (SIP) is an overall security policy with the goal of preventing system files and processes from being modified by third parties. To achieve this, it has the following concepts:

• File system protection
• Kernel extension protection
• Runtime protection

File system protection

SIP prevents parties other than Apple from adding, deleting or modifying directories and files stored in certain directories:

/bin
/sbin
/usr
/System

Apple has indicated that the following directories are available for developers to access:

/usr/local
/Applications
/Library
~/Library

All directories in /usr except for /usr/local are protected by SIP.

It is possible to add, remove or change SIP-protected files and directories via an installer package which is signed by Apple's own certificate authority. This allows Apple to make changes to SIP-protected parts of the OS without needing to change the existing SIP protections.

The certificate authority in question is reserved by Apple for their own use; Developer ID-signed installer packages are not able to alter SIP-protected files or directories.

To define which directories are protected, Apple has currently defined two configuration files on the filesystem. The primary one is found at the location below:

/System/Library/Sandbox/rootless.conf

where rootless.conf lists all the applications and the top-level of directories which SIP is protecting.

Applications

SIP is protecting the core apps which OS X installs into Applications and Applications Utilities. This means it will no longer be possible to delete the applications which OS X installs, even from the command line when using root privileges.

Directories

SIP is also protecting a number of directories and symlinks outside of /Applications and the top level of those directories are also listed in rootless.conf.

In addition to protections, Apple has also defined some exceptions to SIP's protection in the rootless.conf file, and those exceptions are marked with asterixes. These exemptions from SIP's protection mean that it is possible to add, remove or change files and directories within those locations.

Among those exceptions are the following:

• /System/Library/User Template - where OS X stores the template directories it uses when creating home folders for new accounts.
• /usr/libexec/cups - where OS X stores printer configuration information

Apple considers this file theirs and that any third parties' changes to it will be overwritten by Apple.

To see which files have been protected by SIP, use the ls command with dash capital O in Terminal:

ls -O

SIP-protected files will be labeled as restricted.

One important think to know is that even if a symlink is protected by SIP, that does not necessarily mean that the directory they're linking to is being protected by SIP. At the root level of an OS X El Capitan boot drive, there are several SIP-protected symlinks pointing to directories stored inside the root-level directory named private.

However, when the contents of the private directory are examined, the directories which those symlinks point to are not protected by SIP and both they and their contents can be moved, edited or changed by processes using root privileges.

In addition to the list of SIP exceptions which Apple has set in rootless.conf, there is a second list of SIP exceptions. This list includes a number of directories and application names for third-party products. Similar to rootless.conf, this exclusion list is Apple's and any third parties' changes to it will be overwritten by Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Runtime protection

SIP's protections are not limited to protecting the system from filesystem changes. There are also system calls which are now restricted in their functionality.

• task_for_pid() / processor_set_tasks() fail with EPERM
• Mach special ports are reset on exec(2)
• dyld environment variables are ignored
• DTrace probes unavailable

However, SIP does not block inspection by the developer of their own applications while they're being developed. Xcode's tools will continue to allow apps to be inspected and debugged during the development process.

For more details on this, I'd recommend taking a look at Apple's developer documentation for SIP.

Kernel extension protection

SIP blocks installation of unsigned kernel extensions. In order to install a kernel extension on OS X El Capitan with SIP enabled, a kernel extension must:

1. Be signed with a Developer ID for Signing Kexts certificate
2. Install into /Library/Extensions

If installing an unsigned kernel extension, SIP will need to be disabled first.

For more information on managing SIP, please take a look at the link below:

System Integrity Protection – Adding another layer to Apple’s security model