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?

"What does it actually mean for the user experience and the developer experience?" I've been running the beta since available, and this is the first I've heard of it. sudo and password prompting have worked as normal/previously/expected. So, probably the answer is "most of the time you won't notice; when you do, you'll notice hard."
– OJFordAug 20 '15 at 10:41

3 Answers
3

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.

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).

But please stop and think before disabling SIP, even temporarily: 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.

Nice, thanks. I asked this question because I was about to link to that quora article on another Stack Exchange question and then realized that was not the correct move ;-)
– JoshJun 28 '15 at 0:18

15

...Also this totally makes me want to write a kext or something to allow myself to create a binary which I can run in the command line to return to unrestricted access!
– JoshJun 28 '15 at 0:20

if I disable SIP will I get full root or still I am restricted to /sbin, /user, etc directories? @GordonDavisson
– Abhimanyu AryanNov 26 '15 at 20:56

1

@Vladimir Sorry, I don't have any inside information on Apple's plans. My guess would be that it'll stick around for the foreseeable future, although I wouldn't be surprised if it (and SIP itself) changed significantly in the next few versions.
– Gordon DavissonFeb 17 '16 at 21:40

4

There are moments when I hate Apple. I appreciate making it hard to shoot yourself in the foot (years ago I once accidentally catted a text file into my MBR on Linux), but there are times when you do need to e.g. put an additional link in /usr/bin, and having to go through the process of disabling an otherwise nice protection just for that purpose is too paternalistic and annoying. An extra dialog with warnings would have been enough.
– MarsApr 2 '17 at 17:26

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...

Also, I have downvoted this answer as it doesn't answer the question, namely: What is the "Rootless" feature of El Capitan at a technical level? Will sudo -s still work, and, if so, how will the experience of using a shell as root change?. This answer seems to talk only about DTrace
– JoshOct 1 '15 at 3:02

23

I think the answer speaks plainly and precisely to a good part of the question, which is how the experience of using a shell as root will change. Sudo is now pseudo sudo. A layer of architecture has, in fact, been added. Seems relevant to me. And to this man's livelihood. Why down-vote that?
– sas08Oct 3 '15 at 7:53

5

@patrix I don't understand the epistemological distinction. What things are and what they do, and why they exist are intimately related. Sure this post starts en medias res talking about one feature, but it scopes out well. Asking "how does this change the developer experience?" etc. is in point of fact an open ended and subjective invitation to have developers talk about their experiences. Posing these questions in juxtaposition to a vague and overstated objection "the world will end because we can't root" seems to dismiss the idea of harm; this demonstrates harm to the dev experience.
– sas08Oct 9 '15 at 13:08

4

I'm not going to add any more info Josh, because I would just be copying what the other answers have said and not really be adding anything to the page. It would perhaps be better if the top answer included some more info about DTrace no longer working, and then I would remove this answer as redundant :) The other answer is just a carbon-copy of arstechnica.com/apple/2015/09/os-x-10-11-el-capitan-the-ars-technica-review/9/ linked in the top comment, so that could go too. But some things in this answer, like DTrace not working even with SIP off as sudo, is no where else on the net but here
– J.JOct 15 '15 at 20:28

3

The only thing I have figured out so far is that if you disable SIP for DTrace, you can attach to processes that aren't under restrictive entitlements, which since El Cap is everything that comes with the system (like Safari). There is a "dumb" way, which is to copy all system binaries to a new directory like /rootless (with the same directory structure), then make a chroot for /rootless. Now everything is run entitlement-free and can be attached too. The smarter way is to re-mount your filesystem, but im scared to say how/why because Apple will no doubt lock that loophole down...
– J.JNov 27 '15 at 14:33

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.

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.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).