Open Radar

 
Summary:
Secure Kernel Extension Loading negatively affects usability for end users and as a result makes the experience less secure overall. It is also not manageable for organizations with any business need to ensure the functionality of kernel extensions in its current implementation.

Steps to Reproduce:

Install file sync, audio driver, printer, virtualization, hardware accessory, or security product. All of which are properly signed with certs approved by Apple.

Expected Results:
Signed kernel extensions are loaded and functional.

Observed Results:

The kext is not loaded. At time of install, a confusingly-worded prompt mentions a name (the Subject Common Name field) which would almost always not be the same as the product users would have seen as the window title during the install. Users are not allowed one-click opening of the appropriate System Preferences -> Security pane. Only during a 30-minute window and when the kext is attempted to be loaded again the end user may enable the kext. If multiple directories contain kexts by the developer, or the developer used different TeamIDs for the products in their suite, multiple checkboxes are observed.

Version:

10.13 Beta 4

Notes:
The strategy to address this change proposed in Technical Note TN2459 falls short of reasonably addressing any business concerns. Getting every new computer into an environment where spctl can run to perform whitelisting is contrary to Apple guidance to not maintain imaging infrastructure. Unlike GUI whitelisting, exceptions or disabling of this new behavior via spctl can be reset with NVRAM. This makes enterprise IT less confident that loading signed kexts can't (inadvertently or otherwise) be directly circumvented - in departments where use of these kexts are compliance-mandated this will remove the option of purchasing or using Macs