As part of the pre-release announcements about macOS High Sierra, Apple released the following KBase article:
- Prepare your institution for iOS 11, macOS High Sierra, or macOS Server 5.4: https://support.apple.com/HT207828
As part of the KBase article, Apple included a Changes coming with macOS High Sierra section which featured this note:
macOS High Sierra introduces a new feature that requires user approval before loading new third-party kernel extensions. This feature will require changes to some apps and installers in order to preserve the desired user experience.
That section in turn links to this KBase article, which describes the behavior in more detail:
- Prepare for changes to kernel extensions in macOS High Sierra: https://support.apple.com/kb/HT208019
To improve security on the Mac, kernel extensions installed with or after the installation of macOS High Sierra require user consent in order to load. This is known as User Approved Kernel Extension Loading. Any user can approve a kernel extension, even if they don’t have administrator privileges.
What’s all this mean? For more details, see below the jump.
Apple has been trying to discourage third party software developers from using kernel extensions for the past few years. The reason for this has been that kernel extensions are able to plug into the macOS kernel’s space and access low-level resources, like hardware devices. The issue for Apple is that, when kernel extensions aren’t working right, the whole OS has problems that wouldn’t otherwise happen.
As an example of this, if an application which doesn’t use a kernel extension has a memory error, the worst consequence is that the affected application crashes. The rest of the OS is fine though, thanks to the OS’s memory protections. However, if a kernel extension has a similar issue, the kernel doesn’t have similar memory protections. A memory error in a kernel extension can cause a kernel panic, which crashes the whole operating system.
As a result, starting with OS X Mavericks, Apple has been making changes to how third party kernel extensions have been allowed to operate:
OS X Mavericks
Kernel extensions should be digitally signed using an Apple Developer ID for Signing Kexts certificate, but this code signing requirement is not enforced strictly. Unsigned kernel extensions can still be installed into /System/Library/Extensions, which is where kernel extensions have been installed up until OS X Mavericks. However, signed kernel extensions must be installed into /Library/Extensions.
OS X Yosemite
Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. However, it is still possible on OS X Yosemite to enable a kernel extension developer mode which disables the code signing requirement.
OS X El Capitan
Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection, introduced as part of OS X El Capitan, now enforces code signing and explicitly disables the kernel extension developer mode previously available in OS X Yosemite.
macOS Sierra
Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism.
macOS High Sierra
Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism. Kernel extensions will not load unless authorized to do so by a logged-in user.
Note: This authorized user does not need to have admin rights, so any logged-in user can authorize the loading of a kernel extension.
What are the likely consequences of this change in High Sierra?
- For the individual consumer owner of a Mac, this will likely not be a big deal. Since anybody can authorize the loading of the kernel extension, the individual can go click whatever is needed and continue on with their day. Potentially not a great user experience, but not awful.
- For Mac admins, this change is potentially going to be a huge pain in the neck. A number of third-party applications used in education and enterprise environments use kernel extensions, especially antivirus and other security-focused solutions. Now these kernel extensions are not going to load automatically and it’s going to be up to the individual users who use those machines as to whether or not those kernel extensions get loaded.
That said, Apple has stated that third-party kernel extensions won’t require authorization under the following conditions:
- The third party kernel extension(s) in question were on the Mac before the upgrade to macOS High Sierra.
- The third party kernel extension(s) in question are replacing previously approved extensions.
Apple has also provided a couple of ways that companies, schools or institutions can deal with this issue:
1. Boot into macOS Recovery and use the spctl command line tool.
Note: Apple has not yet specified how this tool should be used in High Sierra’s Recovery environment. The guidance provided is Run the command by itself to get more information about how to use the spctl command.
Another section of this KBase article also notes that resetting NVRAM will revert the Mac in question back to requiring user authorization to load kernel extensions.
2. Enroll your Macs with a mobile device management (MDM) solution. If a Mac is enrolled with an MDM solution, even if that MDM solution isn’t being used to actively manage the Mac in question, the new kernel extension authorization behavior is disabled and kernel extension behavior goes back to that enforced by macOS Sierra:
Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism.
Conclusion
Apple is advertising these changes now so that Mac admins can have at least some chance to prepare their environments before macOS High Sierra is released in the fall. For those shops which are already using a mobile device management solution with their Macs, the new kernel extension behavior should be a non-event on High Sierra’s release day. High Sierra should detect that the Mac is enrolled in MDM and revert to macOS Sierra’s behavior of automatically allowing properly signed kernel extensions to load.
For those shops which aren’t currently using a mobile device management solution with their Macs, they currently appear to have the following choices for macOS High Sierra:
- Allow their user population to handle the new kernel extension authorization process
- Use the new macOS Recovery-based process of using the spctl tool in the Recovery environment to disable the new kernel extension behavior
- Get a mobile device management solution and enroll their Macs running macOS High Sierra.
