This is your reminder that having SIP turned off allows trivial escalation to root and disabling part of SIP is broadly equivalent, security wise, to disabling the whole thing
@saagar It’s broadly equivalent to running Mac OS X 10.10 and earlier.
@saagar Why not?
@lapcatsoftware SIP is now the only line of defense for many things
@saagar There was a defense before SIP?
@lapcatsoftware Assuming they didn’t just let you log in without a password sure
@saagar Could you be less vague? You said it was a reminder, but I’m not reminded of anything, and if I’m not, then I’m not sure who would be.
@lapcatsoftware @saagar not sure exactly what saagar is thinking of, but there are various entitlements which grant an executable root-like abilities as a normal user, and without sip, not much is there to stop a malicious process from granting entitlements to other executables under its control
@joe @lapcatsoftware Exactly this. The post above was a reference to the time Apple accidentally allowed anyone to log in without a password which of course did not involve SIP at all

@saagar @joe I’m confused. Are you referring to the High Sierra “I am root” bug, which you admit that SIP did not protect against? If so, then why would you mention that in this context? It’s a red herring and feels obscurantist.

So far, neither you nor Joe have given a single specific example, which again, is a reminder of absolutely nothing.

@saagar @joe I respect your technical knowledge, but explaining it to other people is a different matter.

I’ve spent a lot of time and effort over the years trying to explain things to people, for example on my blog.

You seem to assume that people know what you’re talking about, but frankly, they usually don’t.

@lapcatsoftware @joe I was joking because I assumed you were as well by asking whether there were any defenses before SIP. I figured the answer to this was obvious; a system without SIP that lets you instantly escalate to root would be considered broken.
@lapcatsoftware @joe This is a reminder because I’ve been saying this for a while to various people and it’s not even something I wrote about first, https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e501121 is a good early example. They are not super hard to find and easy to “exploit”
Exploit for IPWnKit: an unintended solution for Defcon Qualifier CTF 2018 that may blow your mind

Exploit for IPWnKit: an unintended solution for Defcon Qualifier CTF 2018 that may blow your mind - README.md

Gist
@joe @lapcatsoftware I don’t expect you to know the complete anthology of my posts and I’m happy to explain but I didn’t give specifics earlier not to be annoying but to avoid the idea that if Apple patches this one way to do it the problem is solved. It’s a general issue.

@saagar @joe I got an AppleScript error, NSXPCConnectionInterrupted, perhaps because it’s running the script as Setup Assistant.

But I’m presuming that the vulnerability is the ability to create a new admin user with known password, and the specific exploit is inessential?

@saagar @joe How did Setup Assistant app work in Mac OS X 10.10 and earlier, though?
@lapcatsoftware @joe I assume it was just being run manually, I think that particular avenue might be blocked now due to launch constraints. I do know I have used either this or something else I found during a CTF to cheese another kernel pwn challenge though
@saagar @joe What I meant was, how was Setup Assistant NOT vulnerable in Mac OS X 10.10 and earlier? Which goes back to my original question, there was a defense before SIP?

@saagar @joe I have an old Mac with Snow Leopard, and I can DYLD_ inject Setup Assistant.

The app quits on its own after launch for whatever reason, perhaps because it was designed to run only once.

@lapcatsoftware @joe I think Library Validation was introduced before SIP but not way back in 10.6
@lapcatsoftware @joe To be clear I am not saying that 10.10 was secure I just don’t think the current state is exactly the same as what we had back then

@saagar @joe Library validation was introduced in 10.10. That’s the point, though: it’s independent of SIP.

The question is whether disabling SIP is worse than not having SIP, and I’m not sure that it is. You seem to blame SIP for the introduction of a root escalation, whereas I wonder whether it was preexisting.

@lapcatsoftware @joe It’s more nuanced than that. If there’s a security bug, and we assume Apple will get around to it someday, without SIP they would fix it in some other way. Wi5 SIP, that is the way they consider it fixed.

@saagar @joe "we assume Apple will get around to it someday"

I don't assume that. ;-)

In any case, it's merely hypothetical speculation. There's no real-world argument that disabling SIP is worse than pre-SIP without real-world examples of post-SIP bugs.

Also, Apple can be publicly pressured. Disabling SIP is supposed to be an outlet for "You can always choose to run any software on your system," which becomes a lie if Apple sabotages that.

@lapcatsoftware @joe Yes. In fact the ability to create a new admin user is also just an example, there’s plenty of undesirable things you can do that this model breaks under. I would imagine bypassing TCC is probably not too difficult with SIP disabled for example

@saagar @joe Bypassing TCC is never too difficult. ;-)

In any case, I still struggle to see how the situation with SIP disabled is worse than the situation with SIP nonexistent. Perhaps you’re overestimating past security?