Hacker News new | comments | show | ask | jobs | submit login
The ‘app’ you can’t trash: how SIP is broken in High Sierra (eclecticlight.co)
294 points by 0x0 9 months ago | hide | past | web | favorite | 96 comments



> 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.


> not just another 'trained to ignore' permissions dialog.

I have never seen any user reading a dialog message if it has a button with label "ok", "cancel", "allow" or "next". Including a lot of developers/dev-ops.


The dialog for kernel extension doesn't contain any of those labels though. Instead it offers you to open the "Security" preference pane where some additional UI will be displayed.

If you blindly click buttons you will not accidentally enable a kernel extension.


I have barely any experience with macOS, but could an application perform those steps on a user's behalf if it were granted Accessibility access?


Every app I've installed that wants accessibility access follows the same steps from the comment you replied to. You must explicitly unlock that pane with your password after clicking the lock and then enable the app to have accessibility access.


It's also possible to detect input events from accessibility. Little Snitch detects and ignores those events (tested via "Synergy" - a keyboard/mouse sharing application), as does the download icon that appears in the upper right corner of iBooks (I don't know why).

The accessibility preferences panel appears to accept those synthetic events, however.


> If you blindly click buttons you will not accidentally enable a kernel extension.

As someone who's gone poking around system internals for twenty-plus years... I can tell you that you're very wrong here. I've forgotten about more completely broken operating systems than I care to discuss, but many of them have ended with me poking around and blindly clicking buttons in a vain hope of getting the OS to do what I want it to do which is apparently frequently different from whatever OS producers want me to do.


You may want to use the workflow yourself to see how it differs and re-evaluate. It surprised me.


This seems a bit hyperbolic. I do, and I'm pretty sure a lot of people do - especially developers; and especially dialogs that you didn't explicitly expect.

Not saying that the majority do; or that a dialog is "good security protection". I just don't think it's as useless as you seem to imply.


It’s exaggerated but only slightly. Some of the worst messes I’ve seen were people who should have known better just blindly pasting google search results because they didn’t have time to do it right.

More developers than sysadmins but definitely not exclusively so. Never underestimate the degree to which people are rushing or not questioning whether their initial diagnosis was correct.


I would add that these kinds of "Normal users click accept/next" are how "offers" on software gets installed.

Case in point: uTorrent. Download and "install". You will, generally, get 2 screens that install junk. On one screen you can click "Decline". On another, you can click "Skip". These screens are between all the normal "which folder", "do you accept" and "thank you" screens.

Case in point: Adobe Reader... download it from their website WITHOUT unchecking the "Optional Offers". You then have a Reader with Benefits.

I consider myself "trained" and "knowledgeable" and I occasionally get bit by these... sidecars... included with desired software.

I have no faith that 95% of people know how to sidestep these "landmines". Decline? that means "don't install". Skip? Why would I skip an important part of the installation.


The problem with most of your examples is that either they're not dialogs ("unclick optional offers"), or they are expected dialogs (you expect during installation dialogs that ask you this-and-that, and you knowingly triggered the installation, so you mistakenly/casually click the wrong button). They are dark patterns, that first train you to click "next-next-next" then present you with an "offer" where you're also expected to click "next".

The system security dialogs like the "permissions" dialogs are not like that - I even read the Android permissions dialog (though I realize most people don't, I still think a sizeable chunk of people do, and thus I considered the original claim - that nobody does, not even developers/dev-ops - to be hyperbolic).


What about the High Sierra notification itself? The only options are "install" and "details"


I've been burned enough by bad installers that I go to ninite for any software like that.


If 1% of the population reads even half of their dialog boxes I'd be amazed.


"trained to ignore' permissions dialog."

Apple users terrify me.


You say this as if every single Windows user in the history of Windows doesn't just click every dialog box that says "OK" or immediately dismiss the UAC boxes that come up when something needs Admin access on Windows 7 and above. On Macs, at least, you have to enter the user's password to do anything damaging.


Watch the average user do something similar with the Windows UAC popup. At least Apple requires a sudoers password for most of theirs.


You can not trust the user. Never.


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


Ask the user what kind of device it wants. (And then when the user says give me the developer hyper bleeding edge pro X, because my mom needs 4K cat videos, then maybe try to persuade the user that the regular non-devkit version would be the sane choice.)

And in the dev version protect the dev mode by some small ritual (like the 7-times tapping on About in Android).


Oh man the hoops I had to jump through to get full admin control over windows 10. I understand the necessity of hiding power options but that was excessive.


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.


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.


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.


> 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.


Make dangerous things hard to do, but not impossible


So someone could make a script simplifying them :)


This is essentially the mindset of iOS, which I think most folks would agree is more secure than macOS. It's much easier to secure a device when you can take this for granted.

Unfortunately, a lot of people still use computers instead of iOS devices explicitly because they want more control and power over what the machine is doing. Security is a lot harder to do in this case.

Ultimately, you can't protect a machine from an empowered user. The best you can hope for is to provide guide rails that make it easier to do the right thing, and harder to do the wrong thing.


I'm an user too and I'd like to be treated like an adult by my operating system.


You’re not the general case.


Does that mean that he shouldn't care about his own experience? Maybe he should just watch American idol, listen to the top 20 pop hits and eat at McDonalds too, because obviously if he isn't in the majority, his opinion dosen't matter.


Good lord that was a hell of a leap of logic you just made. You must be tired after jumping to conclusions and attacking straw men.

Meanwhile, here in reality, the general case is what is design something for (you, btw, were describing lowest common denominator programming - a very different thing with a different, tho related, focus).

Understanding what niche you occupy is key to understanding what products and services are designed for you & which are not. Complaining that you are not catered to as a uncommon case in general purpose product is not only fruitless it’s also foolish.


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.).


I agree with the post --- this is broken behaviour regardless of whether you agree with the security or not --- if you have permissions to install something, you should also have permissions to remove it, and vice-versa.

If you're really into "higher security", then saying they shouldn't have the permissions to install it in the first place would also make sense, but this weird "can install but can't remove" doesn't.


Then the fix is a kext manager where you can remove kexts. Sure it's just language but broken is a tad strong, even though I tend to agree with you.


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).


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.


If that's the user's situation, they should also be in a position to work out a better solution with whatever corporate/school IT is managing the firmware password.

If you're frequently installing and uninstalling buggy kexts, you're pretty far out of the mainstream as a user. Let alone if you also have a firmware password, and it's managed by someone else. Yes, that's a scenario where SIP will be annoying, but it's also not the scenario you can base the security model around for a consumer OS.


On an organization's network, protecting resources from the user is a concept that makes sense.

On personal devices, protecting anything from the user is a backwards and broken model that doesn't respect reality. It's the user's device, they should be able to use it any way they want. There is no need, or desire, to protect it from the user. What we really want to do, is protect the user's data from malicious actors, and getting in the user's way and annoying the crap out of them doesn't accomplish that at all (case in point: ransomware).


> On personal devices, protecting anything from the user is a backwards and broken model that doesn't respect reality. It's the user's device, they should be able to use it any way they want.

I want to be protected from myself. I want my mom to not have to think about how she's using her device in order for her data to be safe.

> What we really want to do, is protect the user's data from malicious actors, and getting in the user's way and annoying the crap out of them doesn't accomplish that at all (case in point: ransomware)

Ransomware (at the time of writing) doesn't impact locked down platforms like iOS.

I'm happy to lose that freedom in exchange for protection!


Then you should be able to get that behavior out of your OS if it is what you want. By all means, give yourself a web kiosk that runs on an overlay fs over a read-only boot media. I've set that up for people.

Ransomware isn't a huge problem on iOS because, like Android, the permissions apply to the application, not the user account. That's a model that makes sense.


> It's the user's device, they should be able to use it any way they want.

Your mistake is conflating what the user authorizing with what the user wants. Nobody wants to install malware but millions of people manage every day. If blaming the user for mistakes was going to be a successful strategy we’d have evidence of that by now but since the opposite is true it’s no surprise that everyone is doing things which actually help people rather than doubling down on wishful thinking.


> Your mistake is conflating what the user authorizing with what the user wants.

Unless you are arrogant enough to believe that you can read the user's mind to know what they actually want, then the only alternative is that you end up with a system that can only be used for the narrow use case you imagine.

This is probably why the Linux Desktop is only really useful as a web kiosk.

>If blaming the user for mistakes was going to be a successful strategy we’d have evidence of that by now

If user-oriented permissions were going to work we'd have evidence for that. Instead what we have is people being infected by ransomware that never needed a privilege escalation at all, because some idiot was so concerned with protecting the OS from the user they forgot to protect the user's data from malicious actors.


> Unless you are arrogant enough to believe that you can read the user's mind

Hint: reading the next sentence will reveal that you are not arguing against a point I made.

> because some idiot was so concerned with protecting the OS from the user they forgot to protect the user's data

Similarly, this is bizarrely wrong: studying recent OS developments would show a strong trend for protecting user data from malicious unprivileged code — and that every improvement has been met with people arguing that this is taking away users’ freedom. Security experts have been arguing for decades that it’s of little value to protect the kernel but still allow someone’s data to be compromised.

The reason why the other work matters is that security depends on layers. If you put in a system which blocks the easy attacks, most attackers aren’t going to give up but will instead switch to more complicated attacks and social engineering has been enduringly effective. Facebook had to add a warning message for the JavaScript console because users were successfully being convinced to copy and paste code which exfiltrated their own session cookies!


Yet in 2017 we only have application level permissions widespread on mobile OSs, and we still bother the user to click "Yes" or run through a sudo prompt to do trivial OS configuration tasks.

Not to mention that this entire discussion takes place in the context of a MacOS "feature" that literally makes it impossible for the user to change the OS configuration.


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.


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


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


Isn't that standard in both APA and MLA?


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?


> 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?


Regardless of the style guides, it’s in the title and not explained until late in the post. The author should have explained or at least expanded the acronym in the lede


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.


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 :/


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).


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)


This may be true, but still I've encountered very few problems installing, updating and removing software on my Mac despite this compared to other platforms I've used. Why would having separate package managers coexist be a bad thing if they can be complementary? (e.g. Homebrew installs different kinds of things than the drag-to-Applications-folder mechanism).


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

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


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.


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.


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


https://developer.apple.com/library/content/technotes/tn2459... 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, 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.”


since any KEXT that’s writable by the user is a huge security risk

Not I disagree, but this is somewhat mitigated because macOS only loads signed kexts by default. I think removal is the larger threat. E.g. if I installed Little Snitch, I don't want other software to be able to remove its kext (though I guess the remainder of Little Snitch is not protected by Little Snitch anyway).


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...


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


> (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.


Apple in general has always been a bit further in this direction, but it seems companies are increasingly leaning towards security over freedom, which is perhaps even more scary than insecurity itself. It's a hard position for a company to be in, but I suppose it comes from the fact that it seems receiving negative PR about being insecure is worse than PR about being unfree.

As a memorable saying goes: "The security people won't be satisified until everyone is living in prison."


When in the history of Mac OS X could you not install kexts?


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.


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).


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


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


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


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.


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...


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.


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


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.


> 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?


Just one antidotal data point, but I haven't had to think about SIP and I updated my OS soon after it was released (I did wait a few months for any issues to surface). The only near-concern I remember was the directory Homebrew used, which either was a non-issue or was addressed over the course of updates. I didn't do anything. I feel like through the course of work I would have hit corner-cases caused by SIP or other macOS "protections."

Out of all the protections added over the years, I only really regularly encounter GateKeeper. I don't generally mind because I know what it is. I don't feel like I'm limited by these things, they feel more like running as non-root user and having to run "sudo" when needed. It makes sure anything silly I might do is done intentionally.

I've had way more issues with SELinux than anything Apple has added to their OS.


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.


> 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.


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.


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.


It took Linux/BSD years to get it right, too. It often takes a long time for the user-facing interface to catch up to the kernel functionality.


> It often takes a long time for the user-facing interface to catch up to the kernel functionality.

A long time to catch up for a company that revolutionized UX?


Revolutions in user interfaces rarely occur overnight. The current Mac is the culmination of over 25 years of continuous development, and it's still imperfect.


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.


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.


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.


One can't remove 'Apple apps' because Apple follows the BSD logic: https://www.over-yonder.net/~fullermd/rants/bsd4linux/01


Apple, protecting the user from himself?

As for removing IE. My understanding is that this would perhaps remove the UI and certain other assets, but the engine and various other bits would remain as the rest of the Windows UI relies on it.

Or at least that seemed to be the technical side of the claim that IE could not be removed during the antitrust trial.


Yeah, IE has at least two parts: "mshtml.dll" which is the rendering engine, and "iexplore.exe" which is the UI frame around it. On my system mshtml is 23MB and iexplore is 800kB, so I think we can infer where most of the logic is.

Microsoft made the integrated help, "active desktop", and I think a few parts of Explorer depend on mshtml.dll.


As well as, what was the first wave of "Electron" apps, thankfully largely ignored.


You forgot to mention Chess. You can't trash Chess.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: