Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > News > Mac News > Pointers: disabling System Integrity Protection (SIP) in El Capitan

Pointers: disabling System Integrity Protection (SIP) in El Capitan
Thread Tools
NewsPoster
MacNN Staff
Join Date: Jul 2012
Status: Offline
Reply With Quote
Oct 21, 2015, 05:41 PM
 
Most of the Pointers we write three times a week have wide appeal. Even if you don't need to do that particular thing at that particular moment, we try to advise users as best as we can on care and feeding of your Apple-related device. However, this Pointers is a little different. Do not do this, unless you absolutely have to. Do not even think you need this information in the front of your brain for general day-to-day OS X use. Read it, store it, remember where you found it, and come back if you need to. Today, we're going to talk about how to disable Apple's new System Integrity Protection (SIP), and why you should or shouldn't do it.

What is SIP?

Apple's System Integrity Protection (SIP), or "rootless mode," has been added to El Capitan as a way to mitigate threats against the OS. As part of SIP, not even root users can write to /usr, /bin, /System, and /sbin. This is of absolutely no concern to most desktop users in itself, but a side effect of the enhanced security is that it will break some software environments, causing problems with drivers for (generally high-end) hardware.

SIP can be disabled, and we're about to show you how. However, even disabling the feature is not always enough to prevent problems with legacy drivers that rely on routine, complete access to prohibited directories -- and you are in effect opening up a big hole in the security of your Mac.

Why would SIP need to be disabled?

Some developers, particularly ones needing low-level hardware access, stored files in prohibited directories. Some of these drivers can be reinstalled with SIP off, and then SIP can be turned back on and all's well. However, some apps require routine access to the system folders that are blocked by SIP. In that case, SIP would need to stay off permanently, which as we stated, we really do not recommend.

If you haven't contacted your hardware vendor for an updated driver, or the developer for a revised version of the app that needs prohibited access, now would be a good time to let them know. Keeping SIP off long-term will likely pose problems down the road, and Apple isn't shy about telling you so after you execute the command. Additionally, we're finding that OS patches may re-enable SIP -- in our brief testing with OS X 10.11.1, we found that some systems that had it turned off had it re-enabled after the update.

So, now that you've made an informed decision about turning the feature off, and all it entails:

How to turn SIP off, and on again

• Reboot into the recovery partition on restart by holding [Command]+[R].

• Choose the "Utilities" menu option, then "Terminal"

• In the terminal window, enter "csrutil disable; reboot" to turn SIP off and reboot

• Do what you have to do in the operating system that required SIP to be shut down. Reboot into the recovery partition.

• Choose the "Utilities" menu option, then "Terminal" again

• In the terminal window, enter "csrutil enable; reboot" to turn SIP back on again, and reboot.

That's it. We don't recommend users keep SIP disabled any longer than they have to. Have we mentioned this? We really don't.

How to check that SIP is really off, and what to do if it isn't

Open a terminal window in your normal operating environment, and enter "csrutil status" -- it should tell you that SIP is enabled, or it will say "disabled" and give you some dire warnings that "this is an unsupported configuration, likely to break in the future and leave your machine in an unknown state." If you get the warning, then SIP is off.

If the status check tells you otherwise, first try the procedure again, and re-check. Should a second attempt fail, it may be that the recovery partition on your system drive hasn't been updated to El Capitan. We've discovered, with the help of a reader, that upgrades very early in the availability of the new OS sometimes failed to update the partition.

The only way around this problem as far as we can glean is to boot from a startup drive with El Capitan that isn't your operating drive, like an installation flash drive that you may have made, or an external drive with the OS on it, and re-run the command.

Afterword

Operating system updates break hardware and software compatibility sometimes. Usually, this is for the greater good. Apple didn't point the finger of judgement at your hack, and tell you that it was going to smite you for heresy, as the Internet outrage about this feature seemingly suggests.

Security threats are escalating. Apple has added SIP as a response, and it is here to stay, for better or worse. The warning that Apple gives when you turn off SIP is dramatic, and implies that at some point, the company will prevent users from turning it off, which will also prevent software from developers that don't follow Apple guidelines about protected directories from working.

So, if there's a migration to do, now's the time to do it, while the old solution still works. If software needs SIP to be disabled, and it's not going to be updated, it's time to look around and find a new application to supplant the SIP-disabling patchwork. If hardware is broken because of SIP, then hassle the vendor about a new driver, or alternatively, find something similar that's compatible.

With OS X, the table is set by Cupertino. When you update to El Capitan, then you can shuffle a bit to make yourself more comfortable at the place setting, and push the unpalatable bits that you've been served to the edge of the plate.

Ultimately, though, you've got to eat all of what Apple's serving if you sit down at the buffet.

--Mike Wuerthele, with contributions from reader Stanley Gallagher
( Last edited by NewsPoster; Nov 3, 2015 at 10:32 AM. )
     
aroxnicadi
Junior Member
Join Date: Jun 2011
Location: Grande Prairie, Alberta
Status: Offline
Reply With Quote
Oct 21, 2015, 06:45 PM
 
wondered what happened over the summer with their beta testing. Sure doesn't seem like it help with all the bugs they found after burning the Gold Master back in September.
     
Charles Martin
Mac Elite
Join Date: Aug 2001
Location: Maitland, FL
Status: Offline
Reply With Quote
Oct 22, 2015, 02:09 AM
 
In fact they had been focusing testing on Mail for some time, but yeah not sure what happened there. The most prominent bug is on MS -- it was working fine in the betas. Compared to say, Snow Leopard's .1 though, this one is relatively smooth.
Charles Martin
MacNN Editor
     
pairof9s
Senior User
Join Date: Jan 2008
Status: Offline
Reply With Quote
Oct 22, 2015, 10:23 AM
 
The biggest casualty of SIP in the software arena has been Default Folder. If you're a DF user, you know how much you miss this feature in El Capitan. Suffice to say, I'll wait for St. Claire to workaround or perhaps give this solution a try, but I'm a "better safe than sorry" kind of guy, so I'm holding off as long as I can.
     
Charles Martin
Mac Elite
Join Date: Aug 2001
Location: Maitland, FL
Status: Offline
Reply With Quote
Oct 22, 2015, 11:20 AM
 
Just to be clear about this: the "problem" SIP exposes is apps that were already violating Apple guidelines. This is not an Apple problem, it's a developer problem.
Charles Martin
MacNN Editor
     
chimaera
Dedicated MacNNer
Join Date: Apr 2007
Status: Offline
Reply With Quote
Oct 22, 2015, 01:00 PM
 
I'm sorry, Dave. I'm afraid I can't do that.

SIP makes the computer refuse orders from the owner. Even when the owner is logged in as root.

It refuses orders for our own good, substituting it's judgement for ours.

Where have I heard this before? Besides Dave, didn't Skynet disobey orders too?

This is a wrong path, it leads nowhere good. If we don't control what we own, they we don't really own it.
( Last edited by chimaera; Oct 22, 2015 at 02:10 PM. Reason: typo)
     
Grendelmon
Senior User
Join Date: Dec 2007
Location: Too F'ing Cold, USA
Status: Offline
Reply With Quote
Oct 22, 2015, 03:15 PM
 
Originally Posted by Charles Martin View Post
Just to be clear about this: the "problem" SIP exposes is apps that were already violating Apple guidelines. This is not an Apple problem, it's a developer problem.
Oh give me a break.

SIP is indeed a "problem." Even with root access you cannot override it within the booted system, which is inexcusable. Apple thinks that they know best, and it's clearly a restriction for the end user. You cannot dispute that.
     
Mike Wuerthele
Managing Editor
Join Date: Jul 2012
Status: Offline
Reply With Quote
Oct 22, 2015, 03:38 PM
 
Charles is right... and so are you. Developers that write to the directories are in fact violating Apple guidelines that they put in place either three or four years ago, I forget. The writing's been on the wall.

It is also a restriction for the end user. The fact that there's a tool at all to disable it, even with a scary warning, is a tacit admission that they knew that this would break stuff.
     
Grendelmon
Senior User
Join Date: Dec 2007
Location: Too F'ing Cold, USA
Status: Offline
Reply With Quote
Oct 23, 2015, 07:21 AM
 
Originally Posted by Mike Wuerthele View Post
Charles is right... and so are you. Developers that write to the directories are in fact violating Apple guidelines that they put in place either three or four years ago, I forget. The writing's been on the wall.

It is also a restriction for the end user. The fact that there's a tool at all to disable it, even with a scary warning, is a tacit admission that they knew that this would break stuff.
The real losers of this move by Apple are the little developers. While MS and Adobe, etc, probably have the size and flex to sway Apple into bending the rules a bit for them, smaller shops or indies have even more constraints when trying to develop apps for the Mac. The net effect is that this will hurt the Mac community with fewer desktop solutions being available.
     
   
Thread Tools
 
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Top
Privacy Policy
All times are GMT -4. The time now is 03:30 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,