20 Feb What Mac Admins Need to Know About Changes to Kernel Extensions in macOS High Sierra
System Extension Blocked! A program tried to load new system extension(s) signed by “Software Vendor.” If you want to enable these extensions, open Security & Privacy System Preferences.Have you noticed a new dialog box popping up on your Macs after installing certain software applications on macOS High Sierra? Unless your Macs are managed with an MDM server, it’s likely you’ve seen this already. According to Apple, “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.”
If you’re unsure of what a kernel extension even is, basically, it’s a mechanism macOS provides for developers as a means of “allowing dynamic loading of code into the kernel, without the need to recompile or relink” the code within the given app.
As a Mac Admin you don’t need to understand the technical details of the kext, but you do need to understand that this change to authorizing is going to impact your environment. And, yes, while it is great that any user can authorize the extensions, unfortunately, many of the programs that use kernel extensions are antivirus programs, hypervisor tools, communication apps, VPNs, and other security products. That means that until your users authorize these extensions (which you know they won’t), your applications will not function as designed.
Now, Apple has stated that there are some situations in which the user will not be prompted and the programs will be allowed to run. Let’s review them and break them down.
- The kernel extensions were installed on the Mac before the upgrade to macOS High Sierra.
- The kernel extensions being installed are replacing previously approved extensions.
- The kernel extensions have been authorized to load without user consent by using the
spctlcommand while booted to macOS Recovery or a NetInstall environment.
- The kernel extensions are installed on a Mac enrolled in Mobile Device Management (MDM). At this time, enrolling in MDM automatically disables User Approved Kernel Extension Loading. This behavior will change in spring 2018.
- The kernel extensions are allowed to load via MDM configuration. Starting with macOS High Sierra 10.13.2, you can use MDM to specify a list of kernel extensions which will load without user consent. This option requires a Mac running macOS High Sierra 10.13.2 which is either enrolled in MDM via the Device Enrollment Program(DEP) or whose MDM enrollment is User Approved.
Kernel Extensions were Installed on the Mac Before the Upgrade or Are Being Replaced
I won’t spend too much time covering these first two bullet-points. The good thing here is that machines upgraded to macOS High Sierra should not behave any different than their macOS Sierra counterparts. What software was installed or is being upgraded will continue to run as their kexts will have be automatically authorized.
Kernel Extensions Have Been Authorized to Load Without User Consent by Using the
If you’re imaging your Macs today, as part of your build process, authorizing specific team IDs for your software vendors is a fairly easy action to add to your provisioning process. You simply need to identify what the team IDs are for your software vendors and run a bash script while in the NetInstall environment. To discover what the team ID is for your software, manually install the software on a test machine that requires a kernel extension. After the software is installed, authorize the kernel extension in the Security and Privacy section of System Preferences. Once installed and authorized, open Terminal and run the following commands:
- sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy
- Once in the sqlite command area, use the command below, paying attention to the case and including the semicolon at the end of the command.
- SELECT * FROM kext_policy;
- Make note of the Team ID which is the bundle of characters prior to the pipe (|). In the example screenshot, the Team ID for VMware is EG7KH642X6.
- While on the Mac, create a new shell script with a text editor (TextMate, TextWrangler, BBEdit, TextMate, Atom, Xcode).
- Copy the following script into your blank file, replacing the set of characters for the appropriate Team IDs. The example script below contains the current team IDs for Palo Alto, Zoom, Cylance, ESET, Parallels, Malware Bytes, and VMWare. Only include the team ID’s in your environment that you’ll actually need.
#!/bin/bash # Palo Alto /usr/sbin/spctl kext-consent add PXPZ95SK77 # Zoom /usr/sbin/spctl kext-consent add BJ4HAAB9B3 # Cylance /usr/sbin/spctl kext-consent add 6ENJ69K633 # VMWare /usr/sbin/spctl kext-consent add EG7KH642X6
# ESET /usr/sbin/spctl kext-consent add P8DQRXPVLP # Parallels /usr/sbin/spctl kext-consent add 4C6364ACXT # Malware Bytes /usr/sbin/spctl kext-consent add GVZRY6KDKR
- Save your script as a .sh file.
- Set execute permissions on your scripts (chmod 755 /path/to/your/script.sh).
Now, you simply need to ensure this script is executed while in the pre-boot environment during your provisioning process. However, there are two notable issues with the process we’ve just outlined. The first being, it’s hard to authorize kernel extensions that your machines will need down the road. Secondly, if the Mac’s NVRAM is reset, all of the changes made will be wiped out. Since resetting the NVRAM is a common troubleshooting step, it’s very likely that you’ll find yourself manually authorizing kexts as if you hadn’t even done this step.
Kernel Extensions are Installed on a Mac Enrolled in Mobile Device Management (MDM)
While it may appear that this step is the easiest way to authorize kernel extensions, it won’t last long. In the Spring of 2018, Apple will require a configuration profile to be applied as well as being enrolled in MDM agent. Moreover, unless the MDM agent was installed with DEP, even the MDM profile is going to need to be manually authorized.
Referring once more to Apple’s documentation, “macOS High Sierra 10.13.2 introduces the concept of “User Approved” MDM enrollment. This new enrollment type is only required if you want to manage certain security-sensitive settings on a Mac whose MDM enrollment is not done through DEP.
Since you can already manage security-sensitive settings on devices whose MDM enrollment is performed via DEP, User Approved enrollment is unnecessary for these devices.
Currently, the only payload which requires either User Approved or DEP-initiated MDM enrollment is the Kernel Extension Policy. However, as new configuration payloads are introduced in future versions of macOS, they might also require User Approved or DEP-initiated enrollment.”
Therefore, until you or the user authorizes your MDM profile, by clicking the Approve button, kexts will not be authorized – with our without the profile whitelisting the Team IDs. Are you convinced you should be using DEP yet?
Kernel Extensions are Allowed to Load via MDM Configuration
OK, so let’s assume you have your Macs in a state where they’re enrolled into MDM and the MDM profile itself has been authorized. At this point, you need to deploy a configuration profile explicitly whitelisting the team IDs. This step is nearly identical to the BASH script discussed above, only this time an XML file will be needed. And while you may have an MDM vendor that has an editor ready for you to build your XML file, not every vendor is there yet.
Reviewing Apple’s developer documentation can help tell you what you need, but it won’t exactly spell things out for you. Let’s look at the Kernel Extension section:
“The Kernel Extension Policy payload is designated by specifying
com.apple.syspolicy.kernel-extension-policy as the
PayloadType value. It is supported on macOS 10.13.2 and later. This profile must be delivered via a user approved MDM server.
In addition to the settings common to all payloads, this payload defines the following keys:
||Boolean||If set to
||Array of Strings||An array of team identifiers that define which validly signed kernel extensions will be allowed to load.|
||Dictionary||A dictionary representing a set of kernel extensions that will always be allowed to load on the machine. The dictionary maps team identifiers (keys) to arrays of bundle identifiers.|
If you noticed the part I put in bold above, you’ll see that you cannot manually install a profile with the specific kext authorizations that you’ve written by yourself. This profile needs to be installed via your user approved MDM server (or at least exported from that server with the appropriate identifiers and then installed manually).
If your MDM vendor has a kernel extensions payload, add in your team IDs and deploy your profile. If your MDM vendor does not yet have a specific payload for kernel extensions, hopefully, they at least have a way for you to create a custom profile. If so, you’ll need to set the preferences domain to com.apple.syspolicy.kernel-extension-policy and then create the AllowUserOverrides and the AllowedTeamIdentifiers keys with the array of AllowedKernelExtensions. I’ve shown an example in the screenshot below for Ivanti Endpoint Manager.
Or, if your MDM vendor allows you to import, you can attempt to use my example config found on my GitHub site. You’ll want to change names and passwords, so pay attention to the XML. Below is an example snippet, but is not the complete XML file.
<key>PayloadContent</key> <array> <dict> <key>AllowUserOverrides</key> <false/> <key>AllowedTeamIdentifiers</key> <array> <string>PXPZ95SK77</string> <string>BJ4HAAB9B3</string> <string>6ENJ69K633</string> <string>EG7KH642X6</string> <string>P8DQRXPVLP</string> <string>4C6364ACXT</string> <string>GVZRY6KDKR</string> </array> <key>PayloadDisplayName</key> <string>Kernel Extension Authorization</string> <key>PayloadEnabled</key> <true/> <key>PayloadIdentifier</key> <string>com.nine41.kernel.extensions.f8227180-efea-0135-0b69-784f435efa83</string> <key>PayloadType</key> <string>com.apple.syspolicy.kernel-extension-policy</string> <key>PayloadUUID</key> <string>f8227180-efea-0135-0b69-784f435efa83</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </array>
Apple has been saying for years that MDM management is the way of the future. No longer can you, as a Mac admin, rely solely on your traditional management agent. And because the MDM agent doesn’t give you full control of the Mac either, you’re going to need to run in a hybrid mode – both with a traditional management agent and the MDM agent.
And, you’ve probably also noticed that Apple is really wanting you to use DEP. If you’re not buying Macs through your DEP account, it’s worth starting now. There simply is going to be more and more hoops to jump through down the road for proper Mac management without DEP.