Secure Kernel Extension Loading: not viable in its current state

Originator:iospiritongt
Number:rdar://32922559 Date Originated:22-Juni-2017 02:58 PM
Status:Open Resolved:
Product:macOS + SDK Product Version:10.13 beta 2
Classification:Enhancement Reproducible:Always
 
Summary:
I applaud your continued efforts of making macOS more secure, but find the current implementation of Secure Kernel Extension Loading in macOS 10.13 to introduce too much friction and confusion for the average user who tries to install legitimate, useful software.

I) PAIN POINTS

Here are the pain points as I see them:

1) Confusing messaging + no shortcuts for users

The "System Extension Blocked" alert gives the average user the impression that an app tried to do something fishy or dangerous and was stopped by the operating system. Or - even worse - that this is a trick alert brought up by the app that tries to trick users into opening System Preferences and removing safeguards there.

Users also aren't afforded the option to directly open the relevant System Preferences pane from that alert.


2) Inconsistent language - and the optics of guiding users through this

After the "System Extension Blocked" alert comes up, users willing to proceed have to open System Preferences themselves, select "Security & Privacy", find the relevant part in the UI (which isn't easy, as the term "System Extension" is absent and now replaced by "System Software") and then click "Allow".

Unfortunately, even if developers decide to guide users through this, the optics of such a guidance just can't be good: it can only consist of instructing the user to ignore a red system warning and making modifications to in a preferences pane called "Security & Privacy".

Finally, providing in-app guidance would also not be an option for kexts that are installed and removed through a System Preferences pane themselves.


3) Apps that install kexts in several locations would lead to multiple prompts

For our driver (Candelair), I've taken a very modular approach, installing only the absolutely necessary kext into /Library/Extensions - and loading additional drivers as necessary from /Library/Application Support/Candelair.

TN2459 makes it sounds as if that will mean that users have to go through the approving process twice - once for the kext in /Library/Extensions, once for the kexts in /Library/Application Support/Candelair:

"If the approved KEXT is located in the application's /Library/Application Support sub-directory, or in /Library/Extensions, all other KEXTs signed by the same Team ID found in that same directory are also approved."

This really just amplifies the issues raised in 1) and 2).

- - -

II) POSSIBLE REMEDIES

I have a few ideas on how the current implementation could be improved without sacrificing any security:

1) Provide a system API to request user consent

That API could look like this:

OSStatus SecKextRequestApproval(AuthorizationRef authorizationRef, NSArray <NSURL *> *kextsToApprove);

And it could be used this way:
a) The app tells the user that it wants to install (a) kext(s)
b) When the user clicks "Install" in the app, the app requests admin priviledges from the user
c) It then passed the obtained AuthorizationRef and an array of URLs pointing to the kexts to install to SecKextRequestApproval()
d) Upon call of SecKextRequestApproval(), macOS validates the authorizationRef, checks code signatures on kextsToApprove and presents information on the kexts and the signing Developer IDs to the user.
e) In this macOS-provided UI, the user can either select "Decline" or "Approve".
f) If the user selects "Approve", macOS adds the referenced kexts to its whitelist, SecKextRequestApproval() returns with noErr and the app can just install and load the user-approved kexts as it could in previous macOS releases.
g) If the user selects "Decline", SecKextRequestApproval() returns with an error - and the app can react accordingly

This hits all the checkboxes:
[x] Can be integrated into any installation flow
[x] User gets prompted for approval
[x] User gets even more information ahead of having to make a decision
[x] No alerts that cast doubts about the legitimaty of the software bundling the kext
[x] No additional steps in System Preferences required (better user experience, less support volume for devs)
[x] No unapproved kexts in /Library/Extensions (and therefore also no accompanying, repeated warnings unnerving the user) 
[x] Malicious code trying to load malicious kexts behind the scenes would still be stopped as going through the SecKextRequestApproval() API (and its requirement for an admin AuthorizationRef) would also expose it. And not going through the SecKextRequestApproval() API would still prompt the "System Extension Blocked" alert and require manual approval in System Preferences.


2) Alternative: add a Review Process for kernel extensions

Such a Review Process would see developers handing in their kexts for review.
If a kext passes the review, Apple would sign it.
The Apple-reviewed kext would then load without bringing up alerts or requiring any other user interaction.

Kexts that did not go through the Review Process would trigger the alert and require explicit user consent.

Given how relatively low the number of actively-developed kexts is, such a Review Process should not require a significant amount of resources to implement.


- - -

III) CONCLUSION

In its current state Secure Kernel Extension Loading in macOS 10.13 does not provide a good experience for either users or developers. In fact, if this feature ships as it is now, shipping a kext becomes a risk for the reputation of legitimate developers due to the optics of this feature's implementation.

This, however, doesn't need to happen. 

By introducing an API like the proposed SecKextRequestApproval() API, users would get more control, more information and a much better user experience. And developers can provide a guided installation covering all steps. All without negatively affecting the intended strong protection against the silent, unapproved loading of malicious kext(s).

Steps to Reproduce:
n/a

Expected Results:
n/a

Actual Results:
n/a

Version:
10.13 beta 2

Notes:

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!