Home > Mac administration, macOS, Management Profiles > Whitelisting third-party kernel extensions using profiles

Whitelisting third-party kernel extensions using profiles

As part of macOS 10.13.2, Apple introduced the concept of User Approved MDM Enrollment (UAMDM). UAMDM grants mobile device management (MDM) additional management privileges, beyond what is allowed for macOS MDM enrollments which have not been “user approved”.

As of macOS 10.13.4, the only additional management privilege associated with UAMDM is that it allows you to deploy a profile which provides a whitelist for third-party kernel extensions. This profile allows a company, school or institution to avoid the need to have individual users approve the running of approved software.

Without the profile, third-party kernel extensions will need to be approved through the User-Approved Kernel Extension Loading (UAKEL) process. Here’s how that process looks:

1. When a request is made to the OS to load a third-party kernel extension which the user has not yet approved, the load request is denied and macOS presents an alert to the user.

Screen Shot 2018 04 11 at 9 16 13 PM

2. The alert tells the user how to approve the loading of the kernel extension signed by a particular developer or vendor, by following this procedure:

A. Open System Preferences
B. Go to the Security & Privacy preference pane

Screen Shot 2018 04 11 at 9 20 45 PM

C. Click the Allow button.

Screen Shot 2018 04 11 at 9 20 22 PM

Note: This approval is only available for 30 minutes. After that, it disappears until the following happens:

i. The Mac restarts
ii. Another attempt is made to load the kernel extension.

Screen Shot 2018 04 11 at 9 20 25 PM

While waiting for the kernel extension to be approved, a copy of the kernel extension is made by the operating system and stored in the following location:

/Library/StagedExtensions

Once approved, another copy of the kernel extension is made and allowed to load.

Screen Shot 2018 04 11 at 9 19 39 PM

This process is relatively easy for an individual to manage on their own computer, but it would be very difficult to manage when dealing with more than a handful of Macs. To help companies, schools and institutions, Apple has made a management profile option available to centrally approve third-party kernel extensions. For more details, please see below the jump.

To help whitelist all kernel extensions from a particular vendor or whitelist only specific ones, Apple has made two sets of identifying criteria available:

  • Team Identifier
  • Bundle Identifier

Team Identifier

A team identifier is a alphanumeric string which appears similar to the one shown below:

7AGZNQ2S2T

It appears to use a developer or vendor’s Developer ID for Signing Kexts certificate identifier. This certificate would be used by a developer or vendor to sign all or most of their kernel extensions.

Whitelisting using the Team Identifier has the advantage of being able to whitelist multiple third party kernel extensions from a specific developer or vendor. This capability allows Mac admins to identify a particular developer or vendor as being trusted in their environment and have all of the relevant kernel extensions be allowed to load by the whitelist.

Note: The UAKEL process appears to use team identity when approving kernel extensions, which potentially allows multiple kernel extensions to be approved at once.

Bundle Identifier

The Bundle Identifier is specific to a particular kernel extension. It is contained in the Info.plist file stored inside each kernel extension.

Screen Shot 2018 04 11 at 9 36 00 PM

Whitelisting using the bundle identifier allows the Mac admin to get very granular about which kernel extensions from a specific developer or vendor are approved and which are not. If using the bundle identifier as part of the whitelist, both the Team Identifier and the Bundle Identifier need to be specified in the profile.

To help Mac admins, a community-written Google Doc spreadsheet is available here which lists various team identities and their associated bundle identifiers:

https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit?usp=sharing

(Hat tip to Contains_ENG for creating the document and developing a script to detect the relevant kernel extension info.)

Using Team Identifier by itself in a third-party kernel extension whitelist profile

If you want to use only the Team Identifier when whitelisting kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

Screen Shot 2018 04 11 at 7 44 53 PM

Screen Shot 2018 04 11 at 7 44 57 PM

Using Team Identifier and Bundle Identifier in a third-party kernel extension whitelist profile

If you want to use both Team Identifier and Bundle Identifier when whitelisting specific kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

Screen Shot 2018 04 11 at 7 39 07 PM

Screen Shot 2018 04 11 at 7 39 13 PM

If you’re using Jamf Pro to deploy a third-party kernel extension whitelist profile profile, it should appear as a built-in profile option. Here’s how it should appear if using only team identifiers:

Screen Shot 2018 04 11 at 7 25 19 PM

Screen Shot 2018 04 11 at 7 41 10 PM

If using both team identities and bundle identifiers:

Screen Shot 2018 04 11 at 7 25 19 PM

Screen Shot 2018 04 11 at 7 25 29 PM

  1. Jarin
    April 12, 2018 at 2:22 pm

    Thank you for this.

  2. Scott
    April 20, 2018 at 11:31 am

    This is great information, with these profiles does this still require a MDM solution ? Can it be used even if your institution does not have an MDM but does have a management tool/utility?

    • April 20, 2018 at 12:01 pm

      An MDM solution and user-approved MDM is a requirement for deploying third party kernel extension whitelist profiles.

  3. April 24, 2018 at 8:23 pm

    Any chance you could do a write-up on how to apply a .mobileconfig with a kernel white list using Munki?

    • April 24, 2018 at 8:25 pm

      Applying a .mobileconfig with a kernel whitelist requires the use of an MDM server. This is an Apple-mandated requirement for the kernel extension whitelist profile.

  4. April 26, 2018 at 12:45 pm

    great article thank you !! also have a question, is it possible to update existing CP with whitelisted kext files, like adding teamids to an existing CP that is already rolled out using Jamf ?

  5. Carl Gruebele
    May 5, 2018 at 3:54 pm

    Very helpful, thank you!

  6. May 22, 2018 at 8:56 pm

    Thank you for this. I have a question, though: My company has not yet migrated to Jamf Pro 10, we’re still on Casper 9.101. I’ve been trying to reverse-engineer a config profile utilizing your xml data for whitelisting by Team ID, set as a custom payload. So far it’s not working (all the directives get deployed to the client machines, but they’re all out of order; is that why? When a supposed-to-be-whitelisted KEXT loads, I still get the alert requesting approval.) Do you know of any way to make this same thing work while being deployed from Casper 9.101?

    • May 23, 2018 at 2:21 pm

      Never mind. Upon further research I believe I’ve answered my own question. It isn’t possible without native support for the specific config profile payload being built into the MDM system. Jamf Pro 10 has this. I’ll just have to light a fire in attempting to accelerate my company’s adoption of Jamf Pro 10.

  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 )

Google+ photo

You are commenting using your Google+ 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 )

w

Connecting to %s

%d bloggers like this: