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