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?


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.

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

  • 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
    Commented Jun 28, 2015 at 0:18
  • 18
    ...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
    Commented Jun 28, 2015 at 0:20
  • 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. Commented Feb 17, 2016 at 21:40
  • 7
    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.
    – Mars
    Commented Apr 2, 2017 at 17:26
  • 2
    The less-intrusive way seems to be disable SIP, edit the master file to remove the restrictions only on the couple of binaries that you really want to replace, and enable SIP again.
    – Joshua
    Commented Nov 5, 2017 at 2:46

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

  • 3
    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
    Commented Oct 1, 2015 at 3:02
  • 32
    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
    Commented Oct 3, 2015 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.
    – sas08
    Commented Oct 9, 2015 at 13:08
  • 5
    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.J
    Commented Oct 15, 2015 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.J
    Commented Nov 27, 2015 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:


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


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:


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

enter image description here


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


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.


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


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .