Home > Mac administration, macOS > Kernel extensions and macOS High Sierra

Kernel extensions and macOS High Sierra

As part of the pre-release announcements about macOS High Sierra, Apple released the following KBase article:

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.

Screen Shot 2017 08 23 at 9 33 49 PM

That section in turn links to this KBase article, which describes the behavior in more detail:

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.


Screen Shot 2017 08 23 at 10 23 34 PM

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/ExtensionsSystem 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

Screen Shot 2017 08 23 at 10 31 55 PM

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.

Screen Shot 2017 08 23 at 10 53 33 PM

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:

  1. Allow their user population to handle the new kernel extension authorization process
  2. Use the new macOS Recovery-based process of using the spctl tool in the Recovery environment to disable the new kernel extension behavior
  3. Get a mobile device management solution and enroll their Macs running macOS High Sierra.
Categories: Mac administration, macOS
  1. cvwong
    August 24, 2017 at 2:43 pm

    Regarding the KBase on macOS High Sierra, I find content cache quite interesting.

    • jbrickley
      August 24, 2017 at 3:12 pm

      I suspect shops running VM’s with macOS Server is not that uncommon. It makes IT sense in a way because all the PC / Linux stuff is virtual lately. Apple really needs to make a change about their VM policies and licensing, create an enterprise version of macOS and license it for virtual use include Server. But there is https://github.com/wdas/reposado that is capable of caching at the least, OS updates. There is Munki and AutoPKG as well. Covers a lot of the same ground that macOS Server Cacheing fulfills and with greater control over things.

  2. jbrickley
    August 24, 2017 at 3:02 pm

    This is a very good thing, except when it comes to security endpoints. The comment about being enrolled in an MDM and disabling the user prompt makes things easier for those managing Macs in environments where an MDM is utilized.

  3. jbrickley
    August 24, 2017 at 3:05 pm

    When the first version of Windows NT (3.1) was released in 1993, reliability was one of the key design goals. So almost all drivers were put in user mode, including printer and graphics drivers. (Disk drivers were kept in kernel mode because if your disk driver fails, your computer is unlikely to ever do anything useful). However, concerns about slow performance made Microsoft put the graphics display system and associated display drivers back into kernel mode for Windows NT 4.0, where they have remained until Vista moved the graphics back into user mode. This greatly reduced the occurrence of the dreaded BSOD (kernel panic) in Vista, 7, 8, 8.1, and 10. It was very common in NT / XP to have a BSOD and trace it back to faulty video graphics drivers.

    Kernel extensions are very dangerous indeed. Kernel mode is very unforgiving.

  4. September 15, 2017 at 1:52 am

    I tried to figure out the spctl command to install a 3rd party extension but couldn’t seem to enable it. Not sure what I am doing wrong. It wasn’t installed before I installed the beta on HighSierra.

    • September 15, 2017 at 3:20 am

      I think I got it figured out. No one said that you had to reboot to install the extension(s) and the Terminal command are only for the not so faint of heart and shouldn’t be messed with by the average user.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: