up vote 134 down vote favorite
67

Apple has introduced System Integrity Protection, also known as "rootless", with OS X 10.11, El Capitan. I understand this is a step for general protection against malware but as a developer I need write access to some of the files it locks away.

How do I disable this protection?

share|improve this question
  • 2
    Even though you can fix all SIP aspects, there are plenty entries for this - remember that by compromising the system, you are building stuff that may not run on your client's machine, where SIP is turned on, and users will not accept turning it off – Motti Shneor Jan 13 '16 at 9:04
  • 3
    @Motti Shneor - However, in some cases this needs to be turned of just to have write access to install some SDKs for development purposes. This would not require the client to do the same. – defaultNINJA Jun 25 '16 at 15:36
  • I came from unix background, trying to understand the logic of rootless: is it because the computer is mostly likely to be single user machine, everything will be installed in the user home directory, so that there is not need to mess with the system directory such as /usr/share/vim/. – Kemin Zhou Mar 18 at 2:42
up vote 131 down vote accepted

Apple's documentation covers disabling SIP, About System Integrity Protection on your Mac and Configuring System Integrity Protection.

An article on lifehacker.com lists these steps:

  1. Reboot your Mac into Recovery Mode by restarting your computer and holding down Command+R until the Apple logo appears on your screen.
  2. Click Utilities > Terminal.
  3. In the Terminal window, type in csrutil disable and press Enter.
  4. Restart your Mac.

You can verify whether a file or folder is restricted by issuing this ls command using the capital O (and not zero 0) to modify the long listing flag:

ls -lO /System /usr

Look for the restricted text to indicate where SIP is enforced.

By default (=SIP enabled), the following folders are restricted (see Apple Support page):

/System
/usr
/bin
/sbin
Apps that are pre-installed with OS X

... and the following folders are free:

/Applications
/Library
/usr/local
share|improve this answer
  • I see from running ls -lO /usr/local is not marked restricted. I've also chownd /usr/local/ recursively. But I keep seeing root take ownership of /usr/local/bin and /usr/local/share which impacts homebrew. Is this the work of SIP as well? – SaxDaddy Oct 9 '15 at 19:38
  • 1
    @SaxDaddy As long as /usr/local is not restricted, you can fix any permissions "below" this directory easily. Homebrew actually recommends to run sudo chown -R $(whoami) /usr/local (while being logged in as an admin user) to fix permission issues. – nohillside♦ Oct 10 '15 at 6:05
  • 4
    @SaxDaddy Are you using Sophos Anti-Virus, by some chance? There is a known issue with Sophos where it changes permissions on those directories. According to a thread on their community forums, it should be resolved in an update due out "soon". – ND Geek Nov 18 '15 at 19:25
  • 1
    @NDGeek: +1: Brilliant, thank you! You called it correctly. And I see that SAV 9.4.1 (released 18nov15) fixed the problem. I have that version installed and confirmed that /usr/local now has permissions set correctly. – SaxDaddy Nov 19 '15 at 20:54
  • 1
    @andro The -O flag does still work in 10.11.6. If it doesn't work for you, that's a separate issue and you should ask a new question. – Mike Scott Sep 5 '16 at 5:49
up vote 91 down vote
+50

It's possible to disable SIP by booting to Recovery HD and running the following command:

csrutil disable

enter image description here

It is also possible to enable SIP protections and selectively disable aspects of it, by adding one or more flags to the csrutil enable command. All require being booted from Recovery in order to set them:

Enable SIP and allow installation of unsigned kernel extensions

csrutil enable --without kext

enter image description here

Enable SIP and disable filesystem protections

csrutil enable --without fs

enter image description here

Enable SIP and disable debugging restrictions

csrutil enable --without debug

enter image description here

Enable SIP and disable DTrace restrictions

csrutil enable --without dtrace

enter image description here

Enable SIP and disable restrictions on writing to NVRAM

csrutil enable --without nvram

enter image description here

I also have a post available with more information about SIP:

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

share|improve this answer
  • 4
    What a welcome wealth of knowledge. I might have to double down on this bounty :-) – bmike♦ Oct 6 '15 at 18:31
  • I get an error: csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS. – Igor Ganapolsky Apr 5 '16 at 15:59
  • 4
    @IgorGanapolsky Read the answer. 'disable SIP by booting to Recovery HD'. – Brick Jun 1 '16 at 14:27
up vote 9 down vote

If the goal is to really just disable System Integrity Protection then booting into the Recovery HD partition as previously recommended in the other answers here via Command+r on boot is not the fastest way to do this.

You can combine single user mode boot with recovery HD boot in an undocumented startup key combination:

This gets you just into the bare minimum environment that is needed for this directly.

share|improve this answer
up vote 4 down vote

If all you need is to access /usr/local, take a look at this page: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

The idea is to temporarily disable SIP using csrutil disable, add /usr/local, use chflags to set that directory to non-restricted

 sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/local

and then re-enable SIP using csrutil enable.

If /usr/local already exists at the time of your upgrade, then even the above isn't necessary. You can simply run

sudo chown -R $(whoami):admin /usr/local
share|improve this answer
  • I keep getting an error: Read-only file system – Igor Ganapolsky Apr 5 '16 at 16:01
  • This link is dead: 404 error. – iconoclast Mar 22 at 22:16
up vote 4 down vote

It would be safer to modify /etc/paths so that /usr/local/bin is merely before usr/bin. That way you can do your development work within /usr/local/bin without having to disable SIP.

Clean installations of the OS have ordered /etc/paths this way since El Capitan, but if you were upgrading the OS from Yosemite or earlier, you'd have to modify the path order manually.

share|improve this answer
  • @iconoclast Before El Capitan, a common convention was to install programs to usr/bin. Since SIP prevents this now, programs should be installed to usr/local/bin, which isn’t restricted by SIP. By putting usr/local/bin first, users can run programs without having to type out the absolute path to the program. Does this make sense? Are you confused about something else? – user260467 Mar 24 at 1:42
  • I've always understood it to be a very bad practice to put anything in /usr/bin... but I guess what I should have asked is "how does this answer OP's question?" I was originally assuming that it did in some way, and that I just wasn't making the connection. But now I'm very doubtful that it has any connection. – iconoclast Mar 24 at 19:34
  • @iconoclast I think it would be irresponsible not to mention to a developer that they really shouldn’t be disabling SIP just to develop an app. – user260467 Mar 24 at 20:03
up vote 0 down vote

If you can't get into Recovery Partition to run csrutil disable, try setting nvram boot args, e.g.

sudo nvram boot-args="rootless=0"
share|improve this answer

protected by Community♦ Dec 16 '15 at 19:50

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

Would you like to answer one of these unanswered questions instead?

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