Saagar JhaThis 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
Jeff Johnson@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
ran mak@saagar @lapcatsoftware none of this makes any sense. if it's trivial, what's the way? i'll report it as a bug.
if you can't tell me what it is, is it a zero day? are reminding us that there are 0-day vulnerabilities at any given time?
only macos uses SIP, so you're saying everyone else is insecure or macos is insecure by design ?
@ranvel @lapcatsoftware What Joe said here: https://f.duriansoftware.com/@joe/116134278291526557. There are always a handful of these present at any given time, and Apple does not consider them bugs because they view SIP as a security boundary so any report that starts with “first, disable SIP…” is discarded
Joe Groff󠄱󠄾󠅄󠄸󠅂󠄿󠅀󠄹󠄳󠅏 (@[email protected])
@[email protected] @[email protected] 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
@saagar I don't know, I think this entitlement thing falls firmly outside of "trivial" anything. Can I still inspect the entitlements of the software in this scenario ? I don't think people who are disabling SIP are running cracked executables or not using other precautions. I personally use Mother's Ruin's Suspicious Package & Archaeology and I regularly audit anything that is persistent with Lingon Pro and Launch Control.
I need to have SIP off because I use dtrace frequently. If you have an odd problem occuring right now in the currently running environment, and it is an intermittent issue, then you can't really restart and temporarily disable SIP.
I think what people who say SIP should always be on are saying "I don't think you have any reason to be running dtrace". I think that is a bold assertion and that's why I replied. I think in the context of your followers, we would be more prone to using dtrace than the general population.
Finally, I understand what you mean when you say "There are always a handful [of these trivial workarounds] at any given time". I believe there may be workarounds at any given time, but I doubt they are trivial. But the other important point about this is that you recognize that these issues are indeed being fixed, and that the revolving door of bugs surrounding this always keeps a few unresolved issues. I think these reports may be deprioritized, but not discarded completely.
@ranvel I’m not making a moral judgement of whether you enable SIP or not. I just think you should have an appropriate perspective of the risks you take when you enable it and what Apple considers to be their security model.
@ranvel I linked this in another thread but I’ll also share here to let you decide for yourself whether this is trivial or not: https://gist.github.com/ChiChou/e3a50f00853b2fbfb1debad46e501121. There are definitely more; I don’t track them closely because they’re not very interesting except as a party trick
@ranvel The key takeaway here is that Apple doesn’t consider that a bug (and, while annoying in general, I kind of understand why) so they’re not obligated to fix this kind of thing, and the shape of this looks very common to me (“system service talks to unprivileged thing”)
@saagar yeah, this is good stuff and i didn’t know about this. i haven’t examined the exploit too closely, but i get what it is doing. i would have expect that flippancy internally, but to get that as a response to a legitimate security concern means that i should probably think hard about what you’ve advised.
i think, unfortunately, this is a reality vs. ideal situation. this is not the security model we want: the tools for evaluation (dtrace) are blocked philosophically and logically by SIP. but, when you disable SIP, you’re not thinking about typical ACLs, you need to go to `dyld`, because for apple-signed (or those with the entitlement) executables it behaves differently.
there are a lot of red flags there.
but also, you have done the rare thing of convincing someone on the internet that they need to reconsider their views.
@ranvel I am generally of the opinion that Apple should open AMFI trusted keys to third party developers