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?

pkamb
  • 8,791
bdnchr
  • 2,053
  • 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 09: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 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 '18 at 02: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 Jan 28 '22 at 21:15

6 Answers6

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
Glyph
  • 1,542
Mike Scott
  • 10,484
  • 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 Oct 09 '15 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 Oct 10 '15 at 06:05
  • @patrix Thanks. I'm still curious because /usr/local is not restricted and chown'd by me daily. Still each day I see those same 2 folders owned by root. I'll troll the console and update if I find the culprit. – SaxDaddy Oct 11 '15 at 00:07
  • As a sidenote: if you ever want to re-enable SIP, just follow those same instructions, replacing csrutil disable with csrutil enable. – Cullub Nov 02 '15 at 13:45
  • 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
  • @SaxDaddy Good to know that was your issue, and that the update resolved it! I'm on a corporate network that hosts the updates locally, so I'm still waiting :-/ – ND Geek Nov 23 '15 at 14:18
  • this saved me a day... searching on the VMWARE error turned up nothing – Tom DeMille Dec 01 '15 at 15:38
  • This worked perfectly. Thanks. Very useful to know. – James Almeida Mar 28 '16 at 17:23
  • There is no -O option to ls on El Capitan 10.11.6. What is the equivalent under this OS version? [And I checked - I ma using O and not zero.] – andro Sep 05 '16 at 01:33
  • 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 05 '16 at 05:49
  • @Mike Scott thanks for twigging me onto this. I was not conscious of using /usr/local/bin/ls (GNU coreutils) as opposed to /bin/ls. That's the explanation. – andro Sep 05 '16 at 12:12
  • Just to add, make sure you use the top level directory, e.g. ll -O /usr, not ll -O /usr/local. – flow2k Jan 02 '19 at 05:12
  • To confirm SIP is disabled run csrutil status – awalllllll Jun 17 '20 at 19:20
  • For Catalina, even after disabling csrutil, the volumes are unwritable. Use the following in order to write to /Systems/: "sudo mount -uw /" – Manish Oct 08 '20 at 10:37
  • @Manish Using Monterey the volumes are indeed still unwritable after disabling SIP but using your suggested command sudo mount -uw / results in the error message: mount_apfs: volume could not be mounted: Permission denied mount: / failed with 66 – Hasen Jul 31 '22 at 12:28
130

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

Rich Trouton
  • 4,152
17

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.

bmike
  • 235,889
LаngLаngС
  • 8,279
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.

user260467
  • 310
  • @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 '18 at 01: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 '18 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 '18 at 20:03
6

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
WHO'sNoToOldRx4Covid-CENSORED
  • 1,216
m_cuffa
  • 69
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:

kenorb
  • 12,695