NEVER disable SIP

In the latest More Power Users, David and Stephen were adamant about NEVER disabling SIP. There is one app that I find invaluable from BinaryAge…TotalSpaces2. It requires SIP to be disabled. I fully trust BinaryAge, but my takeaway from the podcast was that by disabling SIP, you were leaving the door wide open for apps with less integrity. Prior to Mojave, it was OK to reenable SIP. Not now. There is a note in BN’s instructions

Note: Advanced users who want to only partially disable SIP may use the command csrutil enable --without debug --without fs However, csrutil will warn that this configuration is unsupported.

Whaddya think?

1 Like

Yep, disabling SIP is system wide afaik, so you’re not disabling it for that app, you’re disabling it. At least, part of it if that message is correct.

Personally, I can’t imagine coming across an app of that ilk that would be worth compromising my system for.

1 Like

I am an advanced user, former sysadmin and so on. My take: i am not going to disable SIP. My system won’t be “wide open”, but I like every added security layer.

I don’t remember which one it was, but I also had a case of something just working without SIP and I decided to go with an alternative.

Liebe Grüße,

Lars

1 Like

Question… I disabled something in order to allow the Rouge Ameoba apps to work. Was that SIP? I listened to so good advice from people smarter than I am and they did it, so I assume it’s safe. Can anyone shed some light ?

NEVER might be too much…

I disable SIP to change the Catalina login wallpaper and then immediately enable SIP again:

Actually, that’s Binary Age, not Binary Nights.

I disabled SIP when Karabiner-Elements required it. But it doesn’t now, so I don’t, and can’t think of anything that would make me disable it again.

No, it’s different. The Rogue Amoeba apps require permission to install a kernel extension. While a malicious kernel extension could do a lot of damage, the permissions only apply to the Rogue Amoeba extension (unlike disabling SIP which is a systemwide setting).

1 Like

You’re right. I corrected the original post. Sorry for the confusion.

1 Like

Being able to disable it, install an app, and then re-enable it is the equivalent of leaving your house unlocked for an afternoon because you know you have a friend coming over.

Disabling it entirely is the equivalent of just deciding that you never need to lock your front door again, in case a friend ever decides to come over.

I wouldn’t do it.

And perhaps more importantly, due to a much more limited market, I wouldn’t expect an app that requires it to be long for this world. I would definitely not become reliant on such an app.

2 Likes

I ended up going with Mission Control (which I’ve never used). Also, Setapp has an app called Mission Control Plus. I think those will work with having to resort to disabling SIP.

Thanks to all for your comments.

1 Like

Not Even Once.
 

Disabling SIP is not having “your house unlocked”. It is just one of several layers and mechanisms.

If I ignore all other layers (network, permissions, …) it certainly increases the risks. Enabled SIP decreases the risk of other configuration faults.

But I don’t think that just disabling is the equivalent of “open house”.

1 Like

All analogies are imperfect, so maybe not 100% equivalent, but given the sorts of security compromises that are starting to be seen just via things like web browsers I’d say it’s pretty close. It’s at least the same category of consideration.

Obviously this is Windows, but consider CVE-2020-15999, CVE-2020-17087: Google Chrome FreeType and Microsoft Windows Kernel Zero Days Exploited in the Wild - Blog | Tenable®

When somebody can create a webfont file that allows them to break out of Chrome’s “sandbox” and execute arbitrary code on the system, that feels like a pretty wide-open door. Especially for the average user who almost never does system updates.

That’s the whole thing here. SIP to me isn’t just (or even primarily) about the things the user does willingly - it’s about the stuff the user effectively does unknowingly.

1 Like

Awesome… Thanks. I appreciate the response.

[quote=“webwalrus, post:13, topic:21440, full:true”]…
All analogies are imperfect, so maybe not 100% equivalent, but given the sorts of security compromises that are starting to be seen just via things like web browsers I’d say it’s pretty close. It’s at least the same category of consideration…
[/quote]
That’s why I try to keep every layer of added security in place.
Somewhere in the podcast encrypting backups was an issue and somebody stated he didn’t. Considering zero added cost, no added effort, etc. why not?
The problem with exploits is that we only know afterwards what was targeted. So, why disable something? Why is not EVERYBODY using FileVault? Why even discuss IF it makes sense? It does. SIP does. Every layer makes sense. I don’t like the “open door” analogy, because it’s not one layer or feature that defines your security. Ok, if your password is “1234” that would be one of those “open doors”.

The OP started off by giving a reason for disabling SIP.
Now we can argue the relative merits, but there are reasons. The podcast went through the downsiides of having all this security.

For some users it basically comes down to a choice: do you want to risk having your data and identity stolen, or do you want to risk being locked out of your own data?
For me I absolutely want security, but the alternative is a valid option.

Uh… what’s SIP? eyes

1 Like

Yep that was it, I needed it to solve a mayor problem. Turns out it caused more problems. Uninstalled it now need to turn SIP back on :thinking:

We shouldn’t forget developers. Several software products had problems with SIP and turning SIP off was required. Most of them found a way to make the stuff with SIP enabled and updated their products.

So, when SIP was new, I was kind of OK with turning it off. Which I did in 2015. But 2021 I don’t want to turn SIP off because there’s still stuff out there that requires it. An yes, I am aware, that some very rare stuff can’t be done with SIP.