macOS High Sierra – Secure Kernel Extension Loading

Apple takes security very seriously and, with every OS update, changes are made to increase the level of security supplied.

With High Sierra, Apple are adding a new feature called Secure Kernel Extension Loading (SKEL).

Kernel extensions in macOS (kext for short) are modules of code that extend the functionality of the kernel.

It’s worth knowing if you are using any of the following types of software, extensions could be at play:

• Antivirus products
• Audio software
• Code creation tools
• Compliance software
• Communication software
• Drivers for some hardware devices
• File syncing tools
• Video production software
• Virtualization tools

Because they extend the kernel, extensions could prove a security risk, especially if the user of that computer is unaware they were being installed.

Currently kernel extensions must be signed with a valid Developer ID and installed into the /Library/Extensions directory.

With High Sierra, Apple’s forthcoming update to macOS, they are improving security further. However, for businesses and schools who deploy software that include kernel extensions, care will need to be taken.

So what does Secure Kernel Extension Loading do?

Well, before third party kernel extension can be loaded, user approval will be required.

When a third party extension tries to load but has not been enabled, it will be blocked and the user will be presented with a dialog similar to this one, alerting them approval is needed:

To approve the extension, the user should go to System Preferences > Security & Privacy.

This approval user interface (UI) is only present in the Security & Privacy pane for 30 minutes after the alert. Until the user approves the KEXT, future load attempts will cause the approval UI to reappear but will not trigger another user alert.

When a user provides approval, they are actually approving all other KEXTs signed by the same developer Team ID found in the same place as the approved KEXT.

For instance, if the extension was in /Library/Extensions, then all other KEXTs signed by the same Team ID found in that same directory are also approved.

Any user can approve the authorisation, even if they don’t have administrator privileges.

There are some circumstances under which kernel extensions do not require authorisation, as below:

• If they were on the Mac before the upgrade to macOS High Sierra.
• If they are replacing previously approved extensions.
• Also note, in macOS High Sierra, enrolling in Mobile Device Management (MDM) automatically disables SKEL. The behavior for loading kernel extensions will be the same as macOS Sierra.

For companies or schools who do not enroll their computers into an MDM and would rather their users did not have to approve extensions, Secure Kernel Extension Loading can be turned off.

To do this, boot from either the recovery partition, a NetBoot server or any installation environment. From there the spctl kext-consent command can be run. This command can either disable the user approval requirement completely, or specify a list of Team IDs whose KEXTs may be loaded without user approval.

Note: Because the spctl kext-consent stores its values in NVRAM, if you reset the PRAM, the Mac will revert to its default state with SKEL enabled. Resetting PRAM should not really be used for basic troubleshooting like it has in the past.

Having to boot from the Recovery HD or similar is clearly not scalable, so what else can Apple do?

A future update to macOS High Sierra will bring new capabilities to MDM which will allow it to enable or disable SKEL, and manage the list of kernel extensions which are authorised to load without user consent.

This will bring greater flexibility to managing this new layer of security, so if you are not using an MDM, like datajar.mobi, then you are at a disadvantage but if you are, solutions are always available.