Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
6  
"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." – Ollie Ford Aug 20 '15 at 10:41
1  
It's simple - it's a bug mimicking to be a feature. – Wolfgang Fahl Dec 26 '15 at 13:02
    
If someone ever accidentally removes /usr/local and finds itself unable to recreate it, see this answer here. – Lloeki Apr 9 at 8:44
up vote 188 down vote accepted

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

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.

share|improve this answer
1  
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 ;-) – Josh Jun 28 '15 at 0:18
10  
...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! – Josh Jun 28 '15 at 0:20
    
I like to edit Ruby stdlib in /System/Library/Frameworks/Ruby.framework while debugging without need of rbenv. – Nakilon Oct 24 '15 at 15:07
    
if I disable SIP will I get full root or still I am restricted to /sbin, /user, etc directories? @GordonDavisson – Abhimanyu Aryan Nov 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 Davisson Feb 17 at 21:40

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: enter image description here

share|improve this answer
1  
I wonder why you don't just disable SIP if you are keen on DTracing certain programs. – Siyuan Ren Sep 30 '15 at 11:47
2  
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 – Josh Oct 1 '15 at 3:02
12  
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? – sas08 Oct 3 '15 at 7:53
3  
@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. – sas08 Oct 9 '15 at 13:08
1  
@josh above was @ josh. Derp. Can't fix... Stack's "Comment Integrity Protection" system is preventing me after 5 minutes. – sas08 Oct 9 '15 at 13:30

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.

enter image description here

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.

enter image description here

enter image description here

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.

enter image description here

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.

enter image description here

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.

enter image description here

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.

enter image description here

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

share|improve this answer
    
It would be great when screenshots can be replaced with plain text, see: Discourage screenshots of code and/or errors. – kenorb Mar 18 at 22:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.