
The ‘app’ you can’t trash: how SIP is broken in High Sierra - 0x0
https://eclecticlight.co/2018/01/02/the-app-you-cant-trash-how-sip-is-broken-in-high-sierra/
======
misnome
> when some malware does manage to slip an evil kernel extension past a user
> and is rewarded with the protection of SIP, neither the user nor any anti-
> malware tool will be able to remove that extension, unless the user restarts
> from a different boot volume, or KernelExtensionManagement allows it.

But isn't that scenario "Game Over" anyway? At least installing kernel
extensions is a process that is explicit and - importantly - not just another
'trained to ignore' permissions dialog. The alternative would be to prevent
the user from ever installing kernel extensions unless they turn off security,
and then you are back to square one. At least this way, authorised kernel
extensions are taken under protection and not just left lying around for
potential modification?

My main frustruation with SIP has been with environment variables starting
with LD and DYLD being silently swallowed e.g. `DYLD_SOMETHING_SOMETHING=a env
| grep DYLD` gives no output. So if you want to use these variables, or have
existing scripts that do, you have to know what the command you are launching
is - if it's an executable bash script, then the variables will never make it
in.

SIP isn't perfect, and can be frustrating, but it certainly raises the bar for
compromising a whole system.

~~~
felipelemos
You can not trust the user. Never.

~~~
blowski
How does that work in parallel with "It's my device, I'll do what I want with
it"?

~~~
AnIdiotOnTheNet
It doesn't.

We've had user-based permissions in the mainstream on personal devices ever
since XP, and they have totally failed to protect us from anything. It is an
utterly broken, worse than useless, backwards model of security for this class
of device.

If you think I'm wrong, by all means tell me why instead of just downvoting
like some reddit user. I'll happily provide you with a list of all the
ransomware that didn't require even a single elevated permission to ruin
someone's day.

~~~
blowski
From the guidelines:

> Please don't comment about the voting on comments. It never does any good,
> and it makes boring reading.

Better to provide that list without complaining about the downvotes. Even
better would be suggesting how you would improve the system.

~~~
AnIdiotOnTheNet
Even better would be if I just left this hellhole I think. The only difference
between this place and the cesspool of reddit seems to be that people here
think they're better than redditors while behaving exactly the same way.

~~~
jsjohnst
> Even better would be if I just left this hellhole I think.

If that’s what you think about it, then yeah, I agree you should, at least
until you cool off anyway.

------
acdha
This post annoys me for describing a problem which other people might
encounter with a good level of detail but uses “broken” to get clicks rather
than the more accurate “I don’t understand or agreee with the security model”.

As misnome and others have noted, if someone loads a malicious kext the only
safe option is a complete wipe and reinstall – or depending on how much you
trust Apple’s firmware signing, buying a new computer.

This is part and parcel of working in a higher security environment than the
classic Unix model, and it’s not specific to MacOS. I’ve seen people have the
same kind of angry rants about trying to delete immutable files on other
Unixes, disabling SELinix rather than learning how to use it and then
complaining when an auditor dinged it (on .gov systems!), etc. I think it’s
generational for those of us who got started on single-user PCs in the early
or pre-internet era and learned the root=god model as the default without
questioning its suitability for general usage or the modern malware situation
(broad targeting, sophisticated, omnipresent, infections can be permanent,
etc.).

~~~
0x0
It's not just about malware. It's also really annoying if you need to
uninstall a benevolent but buggy kext. And it's quite surprising that SIP+kext
is a one way street (you can install while SIP is active, but you can't
uninstall while SIP is active - hope you're not using a computer where someone
else manages the mac firmware password, or you can end up shooting yourself in
the foot).

~~~
acdha
I agree that it’s annoying but doesn’t that sound like the post should be more
like “here’s the radar number for my request that Apple improve their
documentation”? Most people won’t encounter this and those who do won’t have
much impact from ignoring it.

------
l1ambda
Took me too long to realize SIP in this context is "System Integrity
Protection" not "Session Initiation Protocol". Please spell out acronyms
before using them.

~~~
Skylled
The first usage I see of "SIP" after the title is in parenthesis after the
full phrase.

~~~
jacobsenscott
Yes, but halfway through the article. It is a mystery until then.

~~~
ctrl-j
Isn't that standard in both APA and MLA?

~~~
spiralganglion
Sorry — I don't know what those acronyms mean. I assume they're writing style
guides? (Associated Press.. Acronym? Metropolitan Literature... Acronym?)

Also, is this an example of irony?

~~~
thethirdone
> Sorry — I don't know what those acronyms mean. I assume they're writing
> style guides?

Yes, the guides from American Psychological Association (APA) and Modern
Language Association (MLA)

They are both the main results that appear when you google the acronyms and
are quite common acronyms.

I am surprised you aren't familiar; I would expect that anyone who graduated
from the US (United States of America) school system in the past 20 years
would have heard of them. Are you not from the US?

------
diebir
Meh. Mac OS X package management is irreparably broken to begin with. There is
a "package manager" but... it only knows how to install, not remove packages.

Then the software vendors are divided as to whether the software should be
installed by "dragging" an image into Applications folder, or by running an
installer of some sort, which is usually a package that installs other
packages or some such. Then, there is a Apple store crap on top of all this,
which, if I remember correctly, is also a package manager install.

Apple sucks at software. Mac OS X is stuck in 1995, as far as package
management goes. The consumer does not care, hence Apple has no incentive to
fix this mess.

Apple has a beautiful thing going: the "drag to install" and the self
contained software images. Yet, they won't make any effort to regulate this.

P.S. The "uninstall" process on Mac OS X is usually some sort of a crappy
shell script, which executes various "rm -rf" commands. The reliability and
quality of those commands is left to the creativity of developers, that
normally have no clue and write shell code by looking up examples on the
Internet. It's a wonder uninstalls do not wipe out the whole disk more often.

What. A. Mess.

~~~
Twisell
Meanwhile on my office PC Windows 10 seem still struggling with the concept of
a meaningful progress bar or a readable list of system update (BEFORE
triggering a 2 hours WTF update for obscure reasons).

Apple do know how to manage packet for system update and provide a dumb-
customer-prof one « The AppStore » for paying developers.

If developers write messy scripts how come you would it be fair to blame
apple. And you will find dubious install process on every plateform from dirty
.bat on Win to « easy » makefile for Unix that work after 2 hours of hard
tweaking.

Sorry for the rant :/

~~~
romwell
Well, while your rant is true, I haven't had to deal with BAT files (or even
Powershell scripts) in Windows installs for a very long time.

(One reason for that may be NSIS, bequeathed onto us by Justin Frankel of
Winamp, Gnutella and Reaper fame, which allows for streamlined
(un)installers).

~~~
Twisell
A .bat is the worst case but does NSIS prevent a badly written script? I don’t
think so, it’s still up to the developer to care. Adding an UI on top of a
badly written script will do as much harm as a .bat. (I might be wrong I’m not
familiar with NSIS on the dev side while I confess I used it a lot)

------
nikanj
A lot of people are forgetting that security prompts look like this to
ordinary users
[https://i.imgur.com/H0uVqFer.jpg](https://i.imgur.com/H0uVqFer.jpg)

”But they had to allow installation first” is no defense.

~~~
dpkonofa
In this case, it is, though, because the security prompt to enable the kext in
question doesn't have an "OK" button. It doesn't really offer a button to
perform the action at all. It offers a shortcut to the System Preferences pane
where the user would have to unlock the pane, type in their admin password,
click on the extensions button, and then click to allow the extension. If the
user has jumped through those hoops to enable this, they've already passed the
barrier of entry. This isn't something someone can accidentally do.

------
mikl
Applying SIP on the KEXT makes sense, since any KEXT that’s writable by the
user is a huge security risk. The only thing that appears to be broken here is
the BlueStack uninstaller that is apparently not SIP-aware. There’s probably
some way to do the SIP procedure you did to install the app in reverse.

~~~
0x0
The point of the article is that there's no documented way to do the SIP
procedure in reverse.

~~~
Someone
[https://developer.apple.com/library/content/technotes/tn2459...](https://developer.apple.com/library/content/technotes/tn2459/_index.html#//apple_ref/doc/uid/DTS40017658-CH1-TNTAG4)
gives some more info on the process for approving installation, but doesn’t
mention extension unloading or removal.

Neither does [https://support.apple.com/en-
us/HT208019](https://support.apple.com/en-us/HT208019), but I would guess/hope
that, if you are managing Macs running High Sierra through MDM, you _can_ do
that.

Also, if you are using MDM, be prepared for a change (from that second
document):

 _“If your Mac is running macOS High Sierra and is enrolled in MDM, User
Approved Kernel Extension Loading is currently disabled. All kernel extensions
will load without requiring user consent. Use the Kernel Extension Policy
payload to specify which kernel extensions should load without user consent,
and to optionally prevent users from approving additional kernel extensions.

In spring 2018, an update to macOS will cause User Approved Kernel Extension
Loading to be enabled even on devices enrolled in MDM. You will still be able
to use the Kernel Extension Policy to manage User Approved Kernel Extension
Loading after this change.”_

------
chris_wot
git and other utilities are installed in SIP protected directories. Or are
they? Actually, Apple installs shims for these tools that call on xcoderun,
which runs the utilities in other XCode specific locations.

Just for shits and giggles, I used these Xcode shims to do a stupid hack:

[http://randomtechnicalstuff.blogspot.com.au/2016/05/os-x-
and...](http://randomtechnicalstuff.blogspot.com.au/2016/05/os-x-and-xcode-
doing-it-apple-way.html?m=1)

------
wired_devil
-"MacOs is too closed! Apple lock the user" (Now you can install kernel extensions) -"It's insecure!

~~~
pyre
> _(Now you can install kernel extensions)_

This is wrong. There is no "now." Kernel extensions have been installable in
macOS since 10.0, IIRC. The real "issue" here is that Apple has provided a
mechanism for _installing_ Kernel extensions into a protected bucket, but no
way to _uninstall_ them.

The fact that this whole thing isn't very well (or at all) documented even for
developers (the ones _writing_ the kernel extensions), seems like it's not the
most ideal of situations.

------
agotterer
I ran into SIP yesterday trying to disable the notification center. Why
there's no way to turn it off like every previous version of osx is beyond me.
But basically you have to jump through a bunch of hopes to disable SIPs i
recovery mode before being able to modify the setting to turn off the
notification center.

------
lukealization
Possibly inadvisable, but you can disable SIP in High Sierra by using
`csrutil` from the recovery OS (kind of moot, admittedly, as you'll need to be
in recovery to trash the files that the author has mentioned, but you can at
least make this setting permanent if you're willing to live with SIP
disabled).

------
hauke288
I guess the KEXT gets SIPed so it cant be hijacked by malware...

------
lkuty
Yes it's boring. DTrace is broken too thanks to SIP.

------
xenadu02
If that folder weren’t protected by SIP then malware (or broken installers)
could nuke a desired and approved kext out from under you.

------
twir
Add "System Integrity Protection" to the list of reasons why my next laptop
won't be a Mac. Although based on a free operating system, Mac OS is gradually
taking away users' control over their own devices. Either the user controls
the software, or the software controls the user.

~~~
acdha
Just as with SELinux or AppArmor, you can ignore it if you think your normal
practices keep you safe. That's probably mistaken but it's fully under your
control:

[https://developer.apple.com/library/content/documentation/Se...](https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html)

~~~
twir
I don't mind those features in and of themselves, and I see their value; it's
Apple's paternalistic attitude that bothers me. I've used Macs for my entire
life and always felt I still had a semblance of control over the hardware and
software that I bought, but that feeling of control is going away.

~~~
acdha
How is a feature you can turn off paternalistic? I’d think that argument is
much stronger about iOS.

~~~
twir
Yes, iOS is a better example. I'm not a big fan of closed platforms in
general. I like to be able to decide which software I run on my device, so my
most recent laptop and phone purchases have been GNU/Linux devices.

I understand and appreciate the security advantage that comes with protecting
users from themselves, but at least SELinux and related software still give
users the rope needed to hang themselves if they're into that sort of thing.

~~~
jsjohnst
> but at least SELinux and related software still give users the rope needed
> to hang themselves if they're into that sort of thing.

How’s that not possible on macOS too?

------
ShabbosGoy
I'm glad I didn't upgrade.

Why is it so hard for Apple to get System Integrity Protection right?
Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

~~~
acdha
> Why is it so hard for Apple to get System Integrity Protection right?
> Linux/BSD were hardened years ago with SELinux/AppArmor/MAC etc.

Same reason why you still so commonly find Linux and BSD systems where those
are disabled: the improved security model breaks assumptions people have about
what their code can do and it takes time to redesign code and retrain people.

~~~
ShabbosGoy
What does "improved security model" mean to you? One where the user cannot
access ring0? My thoughts are: It's my fucking machine, I bought it with my
hard earned money, so I should be allowed to do with it whatever I please.

~~~
acdha
Improved security model means not having it be incredibly brittle where the
first time there's a zero day or the user gives the wrong response to a prompt
they lose all of their data and need to completely wipe their system or buy a
new one to recover (note that without full, bug-free firmware signing it's
impossible to trust the system after a compromise).

Yes, you may think that you're going to make that call correctly 100% of the
time day in and day out but even if that does happen to be true, it's not true
for most people. Since Apple's the vendor and they consider trust/privacy a
selling point, they're making decisions which are good for the other 99.999%
of people using computers.

------
OJFord
The article doesn't mention that this is not new; nor is it 'the' app you
can't trash: it joins Safari, Finder, and most other 'Apple apps'.

I find it quite surprising. Even when Windows defaulted to IE without choice,
it could always be removed with 'Add or Remove Windows Features', as I recall.

~~~
Finnucane
I think the difference is that those apps come preinstalled by Apple. Most
users would think, if I install a bit of software, I can remove it later.
That's normal behavior. If the KEXT installation process has a way of getting
software into the special hidey-hole, it should provide a way of getting
software out of it again if it is user-installed.

~~~
OJFord
Wah, I misread then! I thought this was a new Apple-supplied program joining
its others in being non-removable. I agree this is even worse then; I just
also think I should be able to remove Safari, Chess, et al. too.

