195

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?

Improve this question
4
  • 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
    Commented Jan 13, 2016 at 9:04
  • 5
    @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.
    – Iron3eagle
    Commented Jun 25, 2016 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
    Commented Mar 18, 2018 at 2:42
  • The premise of this question is incorrect. As a developer, you emphatically do not need to write to the files it locks away.
    – Glyph
    Commented Jan 28, 2022 at 21:15

6 Answers 6

Reset to default
166

Note: disabling System Integrity Protection is dangerous, and makes your system more vulnerable to malware.

As Apple puts it in the developer documentation about SIP:

Warning

Disable SIP only temporarily to perform necessary tasks, and reenable it as soon as possible. Failure to reenable SIP when you are done testing leaves your computer vulnerable to malicious code.

If you are simply trying to configure system development tools such as vim, python2, ruby and so on, you almost certainly want to be just installing community-maintained versions from Homebrew and configuring those instead. The system-provided tools may be convenient to bootstrap, but if you require SIP exceptions for your daily workflow you are almost certainly doing things in a way which will break in a future version of the operating system, and may break applications and other system functionality in the meanwhile.

Valid reasons to disable SIP yourself might be:

  • if you're doing research on malware yourself in a disposable environment, such as in a macOS virtual machine
  • if you are attempting to modify core operating system functionality for deployment in a highly-specialized environment such as a public-facing kiosk
  • if you require a legacy kernel extension such as MacFUSE on an M1 mac

Also important beyond the security implications is the fact that anything you do on a mac with SIP disabled will not work on anyone else's mac unless they also disable it first. If you're developing mac apps, then your system becomes less useful as a testbed because you don't know if your code only works because you hacked your system. If you're developing for another platform such as deployment to a web server, then you can't share your development environment setup with other developers on your team without compromising their security as well.

Here's how to do it if you really need to:

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
Improve this answer
16
  • 1
    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
    Commented Oct 9, 2015 at 19:38
  • 2
    @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 ♦
    Commented Oct 10, 2015 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
    Commented Nov 18, 2015 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
    Commented Nov 19, 2015 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
    Commented Sep 5, 2016 at 5:49
129
+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

Improve this answer
4
  • 7
    What a welcome wealth of knowledge. I might have to double down on this bounty :-)
    – bmike ♦
    Commented Oct 6, 2015 at 18:31
  • I get an error: csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
    – IgorGanapolsky
    Commented Apr 5, 2016 at 15:59
  • 5
    @IgorGanapolsky Read the answer. 'disable SIP by booting to Recovery HD'.
    – brickery
    Commented Jun 1, 2016 at 14:27
  • i disable it and cant edit my ssh.plist
    – Dimitri Kopriwa
    Commented Dec 23, 2022 at 14:26
16

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.

Improve this answer
0
8

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.

Improve this answer
3
  • @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
    Commented Mar 24, 2018 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
    Commented Mar 24, 2018 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
    Commented Mar 24, 2018 at 20:03
5

If all you need is to access /usr/local, take a look at this page: http://web.archive.org/web/20160117204214/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
Improve this answer
4
  • I keep getting an error: Read-only file system
    – IgorGanapolsky
    Commented Apr 5, 2016 at 16:01
  • This link is dead: 404 error.
    – iconoclast
    Commented Mar 22, 2018 at 22:16
  • Fixed dead link.
    – WHO'sNoToOldRx4Covid-CENSORED
    Commented Apr 10, 2020 at 9:11
  • This is no longer needed, since /usr/local is not protected by SIP anymore.
    – Hjulle
    Commented Dec 21, 2020 at 20:37
2

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

sudo nvram boot-args="rootless=0"

However, if you've got the following error:

nvram: Error setting variable - 'boot-args': (iokit/common) not permitted

then it won't work. You still need to boot it recovery/safe mode.

See:

Improve this answer
2
  • nvram: Error setting variable - 'boot-args': (iokit/common) not permitted
    – mghicks
    Commented Jan 25, 2019 at 0:16
  • 1
    @mghicks In that case, it won't work. I've updated the answer.
    – kenorb
    Commented Jan 25, 2019 at 21:51

You must log in to answer this question.

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