>Of course if Apple’s ultimate goal is simply to continue to wrestle control of the system away from it users, under the guise of ‘security’, I’m not sure any of this even matters
I disagree with this conclusion. All of these features are turnoffable by booting into the recovery system which is available on all macs.
So people who want or need to constantly run unsigned code and load unsigned kernel extensions, they certainly can.
But people who can live with the system protected binaries in the state the Apple shipped them (which is probably the majority of the users) can relax, knowing that (minus issues like the one reported here) malware will have a much harder time to run, much less hide itself.
As long as I can right-click and "open" any binary and as long as I know that I can load unsigned kexts if I really need do, I really don't see a huge issue with this.
That the user can turn off these features by booting into safe mode is beside the point...users can't be expected to do that when installing an app.
Imagine the drop-off rate in your funnel if one of your steps was "boot into safe mode and run these special commands to turn off SIP". Apps that need kernel extensions are rare, but the ones that do aren't just niche developer apps. The office worker running VMWare Fusion to run an old Windows program or any Dropbox user with the Smart Sync feature are all semi-technical audiences that need kernel extensions for their programs to work.
IMHO, the end game for this is that Apple will continue to lock down what apps can do until they have the same level of control on Mac that they do on iOS.
The much more plausible hypothesis is that Apple doesn't care about the Mac app store because they realize it's failed.
The users that can't be expected to boot into recovery mode are the users who shouldn't be loading kernel extensions. Making the system relatively safe by default, with obnoxious ways of subverting those protections for people who (unlike me) want the option of a foot-gun seems like a good balancing act.
I prefer to get all my software, and games, from the Mac App Store if possible. Every time I use a new Mac I'm always glad for the immense convenience; just go into my Purchased items list and click Install on each of the apps I want there, knowing they'll be fully updated and relatively secure compared to downloading from the app's website (see the Transmission ransomware fiasco.)
I just wish Apple brought it into feature-parity with the iOS App Store.
>The office worker running VMWare Fusion to run an old Windows program or any Dropbox user with the Smart Sync feature are all semi-technical audiences that need kernel extensions for their programs to work.
> The office worker running VMWare Fusion to run an old Windows program or any Dropbox user with the Smart Sync feature are all semi-technical audiences that need kernel extensions for their programs to work
VMWare Fusion's .kext is signed with a certificate that's signed by Apple's Kernel signing key, so there is no need to change SIP for Fusion to run.
Besides, since, I believe Maveriks, macOS includes a hypervisor by default that could be used without requiring a kernel module to be loaded (Veertu is in the App Store and does essentially the same thing as VMWare).
Userspace-only apps don't even require a signature to launch them - you can just right-click and select "Open" on the first launch. That's a totally workable compromise.
With regards to apps that require a kernel extension, apple offers three options:
1) if you're a professional software company with a good reputation, you can negotiate to get a signing certificate that can be used to sign your kernel module. This isn't only awarded to big companies either - the makers of Little Snitch certainly don't seem to be a big enterprise and they still got that certificate.
2) For all others, Apple is starting to add more and more knobs in order to allow things that previously needed to run in kernel-space to now run in user-space (see Veertu).
3) If the thing you want to do doesn't (yet) have an official hook and if you are not a company to be trusted with a kernel module signing certificate, then, yes, you will have to force your users to disable SIP, but maybe, that application is fulfilling a very specific need so that this is ok.
Even for me as a moderately advanced user, this is an excellent compromise that provides me with a huge security benefit because even if I am tricked into giving malware my root password, it won't be able to hide its tracks.
With regards to kernel modules, btw, this is even less restrictive than Microsoft who basically only offer you option 1) on 64bit platforms. There is some sort of option 3), but it only persists for one single boot and resets itself back once you reboot the machine - plus, it's nagging you with a warning on the desktop.
Since when did anyone who wanted control of the system use a Mac? Their entire history has been about limiting control. That was always their advantage - for consistent design, easy to use, security, etc. Those are good things people want. Hackers have Linux.
If I understand the situation right, we are no less secure than before High Sierra, just not “more secure” as Apple intended. As such, the obscurity doesn’t buy anything imho.
15 comments
[ 1.8 ms ] story [ 46.5 ms ] threadI disagree with this conclusion. All of these features are turnoffable by booting into the recovery system which is available on all macs.
So people who want or need to constantly run unsigned code and load unsigned kernel extensions, they certainly can.
But people who can live with the system protected binaries in the state the Apple shipped them (which is probably the majority of the users) can relax, knowing that (minus issues like the one reported here) malware will have a much harder time to run, much less hide itself.
As long as I can right-click and "open" any binary and as long as I know that I can load unsigned kexts if I really need do, I really don't see a huge issue with this.
Imagine the drop-off rate in your funnel if one of your steps was "boot into safe mode and run these special commands to turn off SIP". Apps that need kernel extensions are rare, but the ones that do aren't just niche developer apps. The office worker running VMWare Fusion to run an old Windows program or any Dropbox user with the Smart Sync feature are all semi-technical audiences that need kernel extensions for their programs to work.
IMHO, the end game for this is that Apple will continue to lock down what apps can do until they have the same level of control on Mac that they do on iOS.
The users that can't be expected to boot into recovery mode are the users who shouldn't be loading kernel extensions. Making the system relatively safe by default, with obnoxious ways of subverting those protections for people who (unlike me) want the option of a foot-gun seems like a good balancing act.
I just wish Apple brought it into feature-parity with the iOS App Store.
Isn't that exactly what you're arguing against Apple doing for them?
Uh, surely these would be signed?
VMWare Fusion's .kext is signed with a certificate that's signed by Apple's Kernel signing key, so there is no need to change SIP for Fusion to run.
Besides, since, I believe Maveriks, macOS includes a hypervisor by default that could be used without requiring a kernel module to be loaded (Veertu is in the App Store and does essentially the same thing as VMWare).
Userspace-only apps don't even require a signature to launch them - you can just right-click and select "Open" on the first launch. That's a totally workable compromise.
With regards to apps that require a kernel extension, apple offers three options:
1) if you're a professional software company with a good reputation, you can negotiate to get a signing certificate that can be used to sign your kernel module. This isn't only awarded to big companies either - the makers of Little Snitch certainly don't seem to be a big enterprise and they still got that certificate.
2) For all others, Apple is starting to add more and more knobs in order to allow things that previously needed to run in kernel-space to now run in user-space (see Veertu).
3) If the thing you want to do doesn't (yet) have an official hook and if you are not a company to be trusted with a kernel module signing certificate, then, yes, you will have to force your users to disable SIP, but maybe, that application is fulfilling a very specific need so that this is ok.
Even for me as a moderately advanced user, this is an excellent compromise that provides me with a huge security benefit because even if I am tricked into giving malware my root password, it won't be able to hide its tracks.
With regards to kernel modules, btw, this is even less restrictive than Microsoft who basically only offer you option 1) on 64bit platforms. There is some sort of option 3), but it only persists for one single boot and resets itself back once you reboot the machine - plus, it's nagging you with a warning on the desktop.
This is the feature that doesn’t work at the moment. Or rather it works, but it can be bypassed
> can’t release technical details at this time
Then what was the point of the very long post? To grandstand?