macOS security – Secure Kernel Extension Loading (SKEL)

Alex Usov
Jan 21, 2019
5 min read

Some background first

As we get ready to approve kernel extension for our Apple fleet, here is some background on how things evolved.

Kernel extension (KEXT) – MacOS kernel combines the features of a microkernel (load the minimum to run the OS separately from other services) and a monolithic kernel (everything needed for the OS, drivers and filesystem are in the kernel space like BSD). In MacOS, kernel extensions are used by different applications to grant low level access to the hardware. For example, some software, like Antivirus, require access to the computer hard disk and memory to function correctly.

Depending on the skill level of the developers writing these apps, some kernel extensions might be poorly written. There are some apps that don’t even remove the kernel extension when you uninstall them. Others can cause random crashes to your OS or slow down your machine. Apple wants to give the user control over the applications that are installing kernel extension on our Macs and gives the MacAdmins a way to approve them for your fleet.

History

Let’s take a look how the security of Mac OS evolved over time.

OS X 10.8 (Mountain Lion, and earlier, 2012) – Digitally signed kexts are not allowed and wont load.

OS X 10.9 (Mavericks, 2013) – Signed kexts will load but not enforced.

OS X 10.10 (Yosemite, 2014) – Signed kexts enforcement. Your kext will not be loaded if it’s not digitally signed.

OS X 10.11 (El Capitan, 2015) – SIP is now taking care of the code signing verification.

OS X 10.13 (High Sierra, 2017) – Secure Kernel Extension Loading (SKEL) is managed now by System Integrity Protection (SIP).

User Approved Kernel Extension Loading (UAKEL) was introduced to give users control over which kernel extension are allowed to load on their Mac during the software installation.

User Approved MDM (UAMDM) – As an admin, you want to manage certain security-sensitive settings on a Mac to keep security tight. If you use DEP, you are good to go since the device already belongs to your account. The other option is to manually “Approve” additional management privileges from the users computer.

The idea behind this is that some actions have to be approved by the user of the Mac so that a sneaky MacAdmin won’t be able to run items on a user’s personal device without their knowledge. Any user, not only computer administrators, can approve a kernel extension unless restricted by the MDM.

You don’t have to enroll to an MDM to approve kernel extensions manually and can approve them when notified during installation, via the security menu in system preferences.

A few important notes

When you are upgrading to macOS High Sierra or later, all third-party KEXTs that were already installed at the time of upgrading are automatically approved and don’t require any user action.
Automation or attempting to enroll a device remotely via screen sharing will not result in a “User Approved enrollment”. You have to connect a mouse to the device and click a physical button. You can connect via Apple Remote Desktop app and use a USB mouse to click a button if there is no screen connected to the device.
When approving KEXTs manually and if not approved during installation, the approval “Allow” button is only available for 30 minutes after booting, will reappear after a restart in the “security and privacy” -> “general” tab. However, you will no longer see that pop-ups asking you to approve the kernel extension

Back to kernel extensions, once a device is “User Approved” you can use the MDM to whitelist the kernel extension you approve in your organization. More on that below.

Let’s get technical

To identify the KEXT, macOS uses Team Identifier to identify the vendor or Bundle Identifier to identify the specific application installing the KEXT. Here is a community maintained list of known identifiers :

https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit#gid=1070689416

If you want to whitelist the vendor like “Google” you can use their Team ID “EQHXZ8M8AV”. This means that any future KEXTs by Google are automatically approved. If you prefer to whitelist Google File Stream you can use the Bundle ID “com.google.dfsfuse.filesystems.dfsfuse”. However, you must specify the Team ID in both cases

Location of Kernel Extension

Approved and system KEXTs can be found in:

/System/Library/Extensions
/Library/Extensions

Newly installed 3rd party KEXT are copied to the folder mentioned below and once approved, a copy of the extension is made to the one of the folders above and allowed to load.

/Library/StagedExtensions

Working with KEXTs on your mac via CLI

Get info like the Team ID by looking and the KEXTs Info.plist file. Read more about Working with Plist files

/usr/libexec/PlistBuddy -c print /Library/Extensions/Dropbox.kext/Contents/Info.plist

List approved kernel extensions on the Mac

kextstat | grep -v com.apple

Find the location of the kernel extension

kextfind -bundle-id com.getdropbox.dropbox.kext

kextfind -b com.getdropbox.dropbox.kext

Unload until next reboot

sudo kextunload /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext

Load until next reboot

sudo kextload /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext

Remove kernel extensions (should back up just in case)

sudo rm -r /System/Library/Extensions/NAME_OF_THE_KEXT_FILE.kext

Get the Team-ID and Bundle-ID of kernel extensions on your Mac

sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT team_id,bundle_id,allowed,developer_name,flags from kext_policy"

Get the list of MDM approved kernel extensions

sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT team_id,bundle_id,allowed,payload_uuid from kext_policy_mdm"

Get the audit history of kernel approvals on your Mac

sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy "SELECT path,team_id,bundle_id,boot_uuid,created_at,last_seen,flags from kext_load_history_v3"

! Any modifications to the Kernel Extension User Consent must be done from the Recovery OS only !

Add the Team Identifier into the list allowed to load kernel extensions without user consent (from Recovery OS)

sudo spctl add <team-id>

Remove the Team Identifier (from Recovery OS)

sudo spctl kext-consent remove <team-id>

The wrong way to deal with it

If you want to remove this security feature from your environment and are ok with the risk, you can turn off the Kernel Extension User Consent from the Recovery OS. Not recommended.

Boot to recovery and check status of KEXT approval (bad idea)

sudo spctl kext-consent status

Boot to recovery and turn off KEXT approval (bad idea)

sudo spctl kext-consent disable

Boot to recovery and turn on KEXT approval (bad idea)

sudo spctl kext-consent enable

Resetting NVRAM will reset those changes. You can set a firmware password to prevent unauthorized changes.

The easy life with an MDM (JAMF in this case)

As mentioned you must enroll the computer via DEP or “Approve” the newly enrolled device manually. The best way is to use the user enrollment web page by going to:

https://your.jamf.server:8443/enroll

Add a separate JAMF account for each member on the team that can only perform enrollments. This way you’ll have an audit trail of enrollments to your MDM and it simplifies monitoring.

This will install a certificate (if its self-signed) and an MDM config profile. Once this is done, you can push the config profile with the approved KEXT Team or Bundle ID payload to the device.

The approved kernel extension payload must be pushed via an APNS transaction from the MDM server to a Mac. A profile with this payload will not work if it is installed via script and/or package.

Use a separate Config profile and apply it to the Mac before deploying the software that installs the KEXT. You can to deploy all of the kernel extension to all company computers.

Give the profile a general name like “Approved Third-Party System Extensions” to avoid questions from users.

Finally the JAMF payload itself

Now let’s create and deploy the KEXT approval payload with the MDM. Create a new configuration profile and define the desired scope. Add the Approved Kernel Extension payload with the relevant details. Here is that community google sheet link again:

https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit#gid=1070689416

Save and ….. Done.