How to extend system capabilities using Mac kernel extensions and MDM?

Mac security threats are a top of mind concern for organizations as corporate employees are adopting Macs more and more to access the production infrastructure. Most of the Mac apps and installers use kernel extensions to extend the native capabilities of the OS effectively changing what happens deep inside it. But kernel extensions are dangerous in several ways as they lack sophisticated security protections. Apple, therefore, has taken strict measures to kick external agents out of doing nasty things at the kernel level. This blog post goes over how an MDM solution streamlines the process of whitelisting kernel extensions to ensure that all the provisions are in place for optimal Mac security and why system extensions are factoring out Mac kernel extensions for a better security posture.

What are kernel extensions?

Mac kernel extensions (KEXTs) provide the ability for developers to load modules of code at the macOS kernel level dynamically. They are fairly fundamental to extending the capabilities of Mac and deciding what Mac does for the smooth functioning of complex apps. For instance, some antivirus software needs access to the system memory and the computer hard disk. By allowing access to the internal kernel interfaces, Mac kernel extensions give provisions to modify the core operating system components which are required to run a specific app properly.

Many VPN clients, antivirus products, compliance software, DNS proxies, firewalls, audio software, USB drives, file syncing tools, communication software, and other Mac utilities use KEXTs. There are Mac kernel extensions to drive graphic cards, network connectivity, and many more great deals particularly used for security and management purposes. Once a KEXT is added, it grants access to every area of the Mac being a part of the kernel. There are some situations when an app won’t run properly if some extensions are not there and, in such cases, the app developers are compelled to write KEXTs for the apps. The scenarios include:

• The primary client resides inside the kernel.
• Any of the app’s functionality requires access to the kernel interface.
• A userspace app can’t satisfy some special requirements.

User Approved Kernel Extension Loading

For device running macOS 10.13 or later, Apple has mandated explicit user consent for loading kernel extensions. This gave Mac users the entire control over deciding which extensions are allowed to run on their Macs preventing their machines from high-risk activities. With a goal to increase security, any newly installed KEXT needs to be authorized by an admin or non-admin user in order for it to load on the machine. If the user has not yet approved a kernel extension and if a request is made to load it, the load request will be denied and gives an error. This process of granting end users the full control to approve or deny extensions while installing software and thereby preventing kernel level attacks is known as User Approved Kernel Extension Loading (UAKEL).
There are some situations when the kernel extensions do not require approval which include:

• While upgrading to macOS High Sierra, the kernel extensions were already present on the Mac.
• Any previously approved kernel extensions are being replaced by new ones.
• While booted to macOS recovery, kernel extensions are allowed to use the spctl command to load without user consent.
• Kernel extensions are allowed to load using the Kernel extension policy with an MDM.

When a user approves a kernel extension, some other associated kernel extensions also get whitelisted.

• Other kernel extensions in the same application’s bundle with the same team identifier get whitelisted.
• Other kernel extensions signed by the same team ID in the same subdirectory also gets whitelisted if the approved kernel extension is located in the app’s subdirectory inside /Library/Application Support.
• Other kernel extensions signed by the same team ID in /Library/Extensions get approved.

It’s important to note that the User Approved Kernel Extension Loading doesn’t guarantee that all the kernel extensions running on a machine are tamper-free and compatible. However, it will grant users more control to decide what all kernel extensions will load on a Mac and effectively reduce the chances for a system failure or malware attack.

How to approve kernel extensions?

There are two avenues to perform the kernel extensions’ approval. To get the kernel extensions whitelisted, you can either use an MDM or approve locally from the Mac device.

1. Approving kernel extensions locally by end users

It’s not mandatory to enroll the Mac to an MDM to approve kernel extensions. The end users can easily approve them from the Mac system preferences when they are notified to do so while installing the application. The process is as below:

• For loading a kernel extension not having user approval, a loading request is to be made.
• Load request is denied, and an alert box with the name of the developer who signed the kernel extension pops up.
• The alert redirects the users to the system preferences pane.
• The user is prompted to approve the kernel extension from the Security & Privacy pane.
• The Security & Privacy pane disappears after 30 minutes.
• The approval UI reappears until the end user allows the kernel extension if any future requests are made for kernel extension loading but the user alert won’t be shown after the first attempt.

The method doesn’t require a third-party MDM and is simple if you have only a handful of devices to approve the kernel extensions to run on. But for enterprise deployments where it is necessary to manage approvals for a large fleet of devices a more scalable solution is required.

2. Approving kernel extensions using an MDM

A Mac device enrolled in a Mobile Device Management (MDM) solution offers Mac kernel extension whitelisting functionality. To help organizations and schools managing Mac devices, Apple has provided the option to centrally approve kernel extensions orchestrated via an MDM policy using Apple’s MDM or a third-party MDM solution like Hexnode. This feature allows Mac admins to prevent loading third-party extensions on managed devices. Mac admins can use the Kernel extensions policy provided by Apple to:

• Optionally prohibit users from enabling kernel extensions themselves.
• Define the list of kernel extensions that are to be allowed to load without user consent.

Mac kernel extension policy applies to devices running macOS 10.13.2 and newer. Mac administrators can optionally allow users to override kernel extensions, add team identifiers, and whitelist kernel extensions. Apple has made different identifying criteria to help to whitelist kernel extensions easily. The two sets of identifying criteria include:

• Team identifier
  It is a 10-character alphanumeric string generated by Apple associated with the developer account. The team identifier allows to whitelist multiple third-party extensions from a particular vendor and specifically trust a particular developer to allow all the extensions developed by the developer to load on the device.
• Bundle identifier
  Bundle identifiers are unique parameters specific to each kernel extensions. This gives granular control over the kernel extensions and allows us to decide which all kernel extensions from different vendors are to be loaded and which are not.

There are three ways to use these identifying parameters to allow KEXTs:

• Specify the team identifier that signed the kernel extensions.
• Specify the team identifier and bundle identifier of a specific kernel extension.
• Specify only the bundle identifier for an unsigned kernel extension.

Mac kernel extension deprecation

Kernel extensions must be bug-free as any errors occurring to it can affect the entire system. Considering this, Apple has started deprecating some kernel extensions including KAUTH, IOHIDFamily, IOUSBFamily, Network Filter, etc. With the release of macOS Catalina, Apple has introduced system extensions as the modern replacement to kernel extensions. In macOS Catalina 10.15, system extensions run alongside kernel extensions. However, with the release of 10.15.4, system extensions will completely replace kernel extensions and devices running macOS 10.15.4 will not be supporting kernel extensions.

Kernel extensions to system extensions – The changes

Apple’s aim is to improve reliability, security and offer a modern approach to extension distribution. Though KEXTs still do work on macOS Catalina, Apple has deprecated some of the kernel extensions. So, developers should be aware of the transition and should work to move their kernel extensions to the available system extension frameworks.

One of the major benefits of system extensions over kernel extensions is that system extensions work in the user space in place of the kernel extensions which runs in the kernel space. System extensions give more security without requiring kernel-level access. This ensures that the system extensions don’t compromise the stability of macOS or jeopardize the built-in security of the Mac operating system meaning they are less harmful. System extensions with macOS Catalina can be of three types:

• Driver extensions, including network interface cards, drivers to USB, etc.
• Network extensions, including DNS proxies, VPN clients, etc.
• Endpoint security extensions, including anti-virus, endpoint detection, etc.

System extensions can be easily upgraded by updating the applications and removed by deleting the application from the device.

Mac administrators who install extensions for their apps and app developers who develop such extensions have to prepare for this change to Mac kernel extensions and the effective transition to system extensions which are a much secure alternative.