macOS System and Kernel Extensions: A Guide for Apple IT (2024)

Back in 2019, at its Worldwide Developers Conference (WWDC), Apple announced some major changes to the way software developers would be able to interact with macOS. Specifically, the company said that kernel extensions (kexts) would be deprecated in favor of system extensions. That transition is still playing out, even now. Here’s what admins should know about it and how they can use that knowledge to make life smoother for themselves and their users.

What Are Kernel Extensions?

Kernel extensions (or kexts) let developers load code directly into the macOS kernel. By giving developers these kernel privileges, kexts can help those developers create some very powerful apps. Virtualization applications (such as Parallels Desktop or VMWare Fusion), virtual drive services (such as Box and Google Drive), and other software have long used kexts to integrate their code deeply into the Mac.

But that access has some downsides. While kexts have given developers the freedom to build powerful, complex functions, it also presents them with challenges in terms of development, security, and stability.

Because actions taken by kernel extensions occur within the kernel, they’re prioritized over every other function in the system. While this unlocks a lot of freedom for developers, it also creates risks: Even a minor bug could freeze or panic the system.

Beyond the stability challenges that kernel extensions present developers while creating apps, the power of kexts also creates some security concerns. Since one of the kernel’s most important jobs is to define and enforce security policies, and kernel extensions run within it, kexts aren’t governed by macOS security policies. So, if a kernel extension happens to have a bug that leaves it vulnerable to being compromised by malicious actors, it isn’t just the app at risk, it’s the whole system—and no security policy can restrain it.

Today kexts are commonly referred to as “legacy system extensions.” Though many continue to function, they may experience problems, particularly on Mac computers with Apple silicon. Some vendors are still using kexts, but Apple continues to urge them to replace those with system extensions.

For customers who rely on apps that use kexts, we recommend working with the developer to move in that direction. If a developer isn’t willing to do so, we suggest considering alternative solutions.

What Are System Extensions?

To remedy the problems with kexts, Apple introduced system extensions, which provide some similar capabilities to kexts, but in a more controlled environment.

Apple released two new frameworks—the DriverKit framework and the SystemExtension framework—with macOS 10.15. Beyond expanding the safety and stability of macOS, these frameworks could be used as alternatives to kernel extensions and were meant to replace them.

System extensions enable developers to create apps that extend the functionality of macOS without requiring kernel-level access. By leaving the kernel alone, system extensions avoid some of the issues that kexts have had. System extensions allow developers to:

• Develop apps in userspace. Compared to developing apps that would work in the kernel, developing in userspace is much more forgiving. With system extensions, minor bugs won’t lead to kernel-panics or unpredictable system behavior, and developers don't need to worry about managing dynamic memory allocation, synchronization, and latency.
• Develop with more frameworks and languages. When it came to using kernel extensions, developers were limited to using one framework — and they had to write their code in C or C++. Not so with system extensions. Now, developers can use any macOS SDK framework, and they can write code in any programming language they want. (One notable exception: driver extensions, which still must be written in C or C++ and use the DriverKit framework.)

Most importantly, system extensions are a big step up in terms of security. Because system extensions run in userspace instead of the kernel, they run much like an app; bugs won’t affect the entire system, just the software that the system extensions are a part of.

And because system extensions run in userspace, they’re subordinate to the system’s security policies. This takes the main security threat that kexts posed out of the picture, increasing the overall stability of the system.

But that doesn’t mean system extensions lack power. While they can’t perform kernel-level functions, they do have some advanced permissions to do things like use APIs to communicate with the kernel or to get direct access with associated hardware devices.

Extension Detection

It bears repeating that system extensions have been part of an effort by Apple to phase out kexts and create a more stable and secure environment for macOS. But kexts are still out there, in part because some of them use KPIs (Kernel Programming Interfaces) that still do not yet have system extension alternatives yet are needed for some operations.

Which is why users may still see the dialogs that first appeared in macOS Catalina and continue to do so in macOS Big Sur and Monterey, which tell users that the program they wanted to run is using a “legacy system extension”—in other words, a kext.

If you aren’t sure whether the software installed on the devices you manage uses a system extension or a kernel extension, there are a few ways to find out.

First, you can consult Apple’s own support and developer documentation for more information on legacy system extensions and deprecated kernel extensionsor to learn more about system extensions.

If Apple’s documentation doesn’t answer your question, you can search user systems yourself. If you aren’t sure if a kext or a system extension is running, there are tools that will help. We've summarized this in a support article, Kernel Extensions: Overview and Guide.

However you get the Team ID and bundle identifiers of the extensions running on end-user devices, that information will be useful for bypassing prompts via kernel extension and system extension profiles.

Managing System and Kernel Extensions

System extension profiles can define which system extensions can use which system extension frameworks. You can use these profiles to ensure that applications that use system extensions will load on your users’ devices without prompting them for approval. You can implement this in Kandji using a System Extension library item.

To allow system extensions, you have to specify the corresponding team IDs or bundle identifiers. The system can then recognize whether certain extensions should be executed or not.

Ever since macOS High Sierra 10.13, kernel extensions have required User Approved Kernel Extension Loading (UAKEL) to load. UAKEL is exactly what it sounds like: A user must approve kernel extensions that are needed before they can load in macOS, providing positive assent through an Install Kernel Extension dialog. If you know that software is going to generate such dialogs, you can provide documentation or instructions for users, so they understand what these messages mean and how they should respond.

There are special requirements for using kexts on Mac computers with Apple silicon: Security policies must be adapted to authorize their use. (More specifically, the security policy must be changed to Reduced Security before a kext can be installed.)

Devices that are enrolled in MDM with automated device enrollment can be configured to automatically authorize remote management of kernel extensions and change the security policy. In Kandji, you can do so using a Kernel Extension library item.

By contrast, on devices enrolled into MDM via device enrollment or user enrollment, or on devices that aren’t managed by MDM, a local administrator can manually alter the security policy (in macOS Recovery) and authorize remote management of kernel extensions and software updates. Apple has documented all of this in one of its support docs.

Starting with macOS Big Sur, legacy system extensions could load without user consent on both Intel-based Mac computers and Mac computers with Apple silicon. This requires enrollment in your MDM via Automated Device Enrollment or via user-approved enrollment.

If a given device meets these criteria, you can use those Team ID and bundle identifiers discussed above to allow kernel extensions to install and load silently without needing user approval, doing away with prompts that disrupt the user experience.

About Kandji

As macOS continues to phase in system extensions, the Kandji team is dedicated to sharing the latest developments with the IT community and making the most out of the opportunities it presents to push MDM forward. With powerful features like zero-touch deployment, one-click compliance, and offline remediation, Kandji has everything you need to enroll, configure, and secure your devices. It’s time to manage your Apple fleet like your business depends on it.

Note: This post was originally published May 14, 2020, and substantially updated January 7, 2022.