The ‘app’ you can’t trash: how SIP is broken in High Sierra
eclecticlight.co
eclecticlight.co
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.
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.
If you blindly click buttons you will not accidentally enable a kernel extension.
The accessibility preferences panel appears to accept those synthetic events, however.
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.
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.
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.
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 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).
Apple users terrify me.
And in the dev version protect the dev mode by some small ritual (like the 7-times tapping on About in Android).
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.
> 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.
If that’s what you think about it, then yeah, I agree you should, at least until you cool off anyway.
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.
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.
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.).
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.
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 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).
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!
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.
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.
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.
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!
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.
Also, is this an example of irony?
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?
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.
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 :/
(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).
”But they had to allow installation first” is no defense.
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.”
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).
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...
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.
As a memorable saying goes: "The security people won't be satisified until everyone is living in prison."
https://developer.apple.com/library/content/documentation/Se...
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.
How’s that not possible on macOS too?
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.
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.
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.
A long time to catch up for a company that revolutionized UX?
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.
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.
Microsoft made the integrated help, "active desktop", and I think a few parts of Explorer depend on mshtml.dll.