System and kernel extensions in macOS
macOS 10.15 or later enables developers to extend the capabilities of macOS by installing and managing system extensions that run in user space rather than at the kernel level. By running in user space, system extensions increase the stability and security of macOS. Even though kexts inherently have full access to the entire operating system, extensions running in user space are granted only the privileges necessary to perform their specified function.
System extensions support robust management using MDM, including the ability to allow all extensions from a specific developer or of a specific type (like network extensions) to load without user interaction. Optionally, MDM can disallow users from approving their own system extensions from loading.
In macOS 11.3 through macOS 11.6.4, making changes to a system extension profile directly affects the state of an extension. For example, if an extension is pending approval and a configuration profile is pushed that allows the extension, the extension is allowed to load. Conversely, if an approval is revoked, the system extension is unloaded and marked for removal on the next restart of the Mac. If a system extension tries to unload itself, an interactive authentication dialog appears that requires administrator credentials to authorize the unloading.
In macOS 12.0.1 or later, a dictionary in the System Extensions payload—called RemovableSystemExtensions—allows an MDM administrator to specify which apps should be able to remove their own system extensions. No local administrator authentication is required to remove the system extensions. This is especially useful for vendors that may provide automated uninstallers for their apps.
Kernel extensions
In macOS 11 or later, if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. They require the user’s approval and restarting of the macOS to load the changes into the kernel, and they also require that the secure boot be configured to Reduced Security on a Mac with Apple silicon.
Developers can use frameworks such as DriverKit and NetworkExtension to write USB and human interface drivers, endpoint security tools (like data loss prevention or other endpoint agents), and VPN and network tools, all without needing to write kexts. Third-party security agents should be used only if they take advantage of these APIs or have a robust road map to transition to them and away from kernel extensions.
Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system. Users should prefer solutions that don’t require extending the kernel and use system extensions instead.
Adding kexts on an Intel-based or Apple silicon Mac with macOS 11 or later
If you must use kernel extensions, review the approval methods based on enrollment type.
MDM enrollment type
Approval method
Not enrolled
User Enrollment
When a new kext is installed and there’s an attempt to load it, a restart must be initiated by the user from the warning dialog in:
macOS 13 or later: Apple menu > System Settings > Privacy & Security.
macOS 12.0.1 or earlier: Apple menu > System Preferences, > Security & Privacy.
This restart initiates the rebuild of the AuxKC before to the kernel booting.
Device Enrollment
Automated Device Enrollment
Every time a new kext is installed and there’s an attempt to load it, a restart needs to be initiated by either:
A local administrator account, from the warning in Privacy & Security in System Settings (macOS 13 or later) or the Security & Privacy pane of System Preferences (macOS 12.0.1 or earlier). MDM can also allow this for standard users.
The MDM solution itself, using the RestartDevice command with RebuildCache flagged. The AuxKC rebuilds the next time the Mac restarts. kexts already discovered by macOS (for example, loaded by their software and blocked) are included, and ones that haven’t yet attempted to load can be supplied using the KextPaths key.
Note: A kext allow list profile must first be installed by the MDM solution specifying the kext. macOS 11.3 or later optionally allows MDM to notify the user to complete the restart at their convenience.
Additional steps for adding kexts on a Mac with Apple silicon
If you’re adding kernel extensions on a Mac with Apple silicon, you must take additional steps.
MDM enrollment type
Approval method
Not enrolled
Kext management by the user requires a restart to recoveryOS to downgrade security settings. The user must press and hold the power button to restart into recoveryOS and authenticate as an administrator. Only when recoveryOS is entered using the power button press will the Secure Enclave accept the change of policy. The user must then select the checkbox Reduced Security and the option “Allow user management of kernel extensions from identified developers” and restart the Mac.
User Enrollment
The user must restart into recoveryOS to downgrade security settings. The user must press and hold the power button to restart into recoveryOS and authenticate as a local administrator. Only when recoveryOS is entered using the power button press will the Secure Enclave accept the change of policy. The user must then select Reduced Security, check “Allow user management of kernel extensions from identified developers,” and restart the Mac.
Device Enrollment
The MDM solution should notify the user they must restart into recoveryOS to downgrade security settings. The user must press and hold the power button to restart into recoveryOS and authenticate as an administrator. Only when recoveryOS is entered using the power button press will the Secure Enclave accept the change of policy. The user must then select Reduced Security, check “Allow remote management of kernel extensions and automatic software updates,” and restart the Mac.
To learn if this feature is supported for your devices, consult your MDM vendor’s documentation.
Automated Device Enrollment
(The Mac serial number must appear in Apple School Manager, Apple Business Manager, or Apple Business Essentials, and the Mac must be enrolled in an MDM solution linked to the service.)
MDM solutions can manage this automatically.
To learn if this feature is supported for your devices, consult your MDM vendor’s documentation.
Kernel extensions with System Integrity Protection
If System Integrity Protection (SIP) is enabled, the signature of each kext is verified before being included in the AuxKC.
If SIP is disabled, the kext signature isn’t enforced.
This approach allows Permissive Security flows for developers or users who aren’t part of the Apple Developer Program to test kexts before they’re signed.
Apple Platform Security
CommunitiesContact Support
Search this guide
Search this guide
Table of Contents
Kernel extensions in macOS
Starting with macOS 11, if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. For a Mac with Apple silicon, the measurement of the AuxKC is signed into the LocalPolicy (for previous hardware, the AuxKC resided on the data volume). Rebuilding the AuxKC requires the user’s approval and restarting of the macOS to load the changes into the kernel, and it requires that the secure boot be configured to Reduced Security.
Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system, and Apple recommends users select solutions that don’t require extending the kernel.
Kernel extensions in a Mac with Apple silicon
Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions. This action also requires entering an administrator password to authorize the downgrade. The combination of the 1TR and password requirement makes it difficult for software-only attackers starting from within macOS to inject kexts into macOS, which they can then exploit to gain kernel privileges.
After a user authorizes kexts to load, the above User-Approved Kernel Extension Loading flow is used to authorize the installation of kexts. The authorization used for the above flow is also used to capture an SHA384 hash of the user-authorized kext list (UAKL) in the LocalPolicy. The kernel management daemon (kmd) is then responsible for validating only those kexts found in the UAKL for inclusion into the AuxKC.
If System Integrity Protection (SIP) is enabled, the signature of each kext is verified before being included in the AuxKC.
If SIP is disabled, the kext signature isn’t enforced.
This approach allows Permissive Security flows for developers or users who aren’t part of the Apple Developer Program to test kexts before they are signed.
After the AuxKC is created, its measurement is sent to the Secure Enclave to be signed and included in an Image4 data structure that can be evaluated by iBoot at startup. As part of the AuxKC construction, a kext receipt is also generated. This receipt contains the list of kexts that were actually included in the AuxKC, because the set could be a subset of the UAKL if banned kexts were encountered. An SHA384 hash of the AuxKC Image4 data structure and the kext receipt are included in the LocalPolicy. The AuxKC Image4 hash is used for extra verification by iBoot at startup to help ensure that it isn’t possible to start up an older Secure Enclave–signed AuxKC Image4 file with a newer LocalPolicy. The kext receipt is used by subsystems such as Apple Pay to determine whether there are any kexts currently loaded that could interfere with the trustworthiness of macOS. If there are, then Apple Pay capabilities may be disabled.
Alternatives to kexts (macOS 10.15 or later)
macOS 10.15 allows developers to extend the capabilities of macOS by installing and managing system extensions that run in user space rather than at the kernel level. By running in user space, system extensions increase the stability and security of macOS. Even though kexts inherently have full access to the entire operating system, extensions running in user space are granted only the privileges necessary to perform their specified function.
Developers can use frameworks, including DriverKit, EndpointSecurity, and NetworkExtension, to write USB and human interface drivers, endpoint security tools (like data loss prevention or other endpoint agents), and VPN and network tools, all without needing to write kexts. Third-party security agents should be used only if they take advantage of these APIs or have a robust road map to transition to them and away from kernel extensions.
User-Approved Kernel Extension Loading
To improve security, user consent is required to load kernel extensions installed with or after installing macOS 10.13. This process is known as User-Approved Kernel Extension Loading. Administrator authorization is required to approve a kernel extension. Kernel extensions don’t require authorization if they:
Were installed on a Mac when running macOS 10.12 or earlier
Are replacing previously approved extensions
Are allowed to load without user consent by using the spctl command-line tool available when a Mac was booted from recoveryOS
Are allowed to load using mobile device management (MDM) configuration
Starting with macOS 10.13.2, users can use MDM to specify a list of kernel extensions that load without user consent. This option requires a Mac running macOS 10.13.2 that’s enrolled in MDM—through Apple School Manager, Apple Business Manager, or MDM enrollment done by the user.
Published Date: February 18, 2021
See also
Auxiliary Kernel Collection (AuxKC) Policy Hash (auxp)
Auxiliary Kernel Collection (AuxKC) Image4 Manifest Hash (auxi)
Auxiliary Kernel Collection (AuxKC) Receipt Hash (auxr)
System Integrity Protection
macOS utilizes kernel permissions to limit writability of critical system files with a feature called System Integrity Protection (SIP). This feature is separate and in addition to the hardware-based Kernel Integrity Protection (KIP) available on a Mac with Apple silicon, which protects modification of the kernel in memory. Mandatory access control technology is leveraged to provide this and a number of other kernel level protections, including sandboxing and Data Vault.
Mandatory access controls
macOS uses mandatory access controls—policies that set security restrictions, created by the developer, that can’t be overridden. This approach is different from discretionary access controls, which permit users to override security policies according to their preferences.
Mandatory access controls aren’t visible to users, but they’re the underlying technology that helps enable several important features, including sandboxing, parental controls, managed preferences, extensions, and System Integrity Protection.
System Integrity Protection
System Integrity Protection restricts components to read-only in specific critical file system locations to help prevent malicious code from modifying them. System Integrity Protection is a computer-specific setting that’s on by default when a user upgrades to OS X 10.11 or later. On an Intel-based Mac, disabling it removes protection for all partitions on the physical storage device. macOS applies this security policy to every process running on the system, regardless of whether it’s running sandboxed or with administrative privileges.
