Each of the main security services in macOS, such as XProtect, relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.

Currently, those most frequently updated are XProtect and XProtect Remediator, normally released in two-week cycles. However, Sequoia has changed the way that XProtect’s data is updated, and it’s now intended occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.

This article details each of the main security data files found in macOS 15 Sequoia, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, or left frozen in time, and three have been removed completely; those are listed below for the record. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.

Main Security Data

XProtectPayloads, alias XProtect.app and XProtect Remediator
Latest version: 145, 3 September 2024.
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app on the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every two weeks using Software Update or a substitute.

XProtectPlistConfigData
Latest version: 1.0 5275, 24 September 2024.
These are the whitelists and blacklists used by XProtect, as detailed here. In Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle, on the Data volume; the secondary is also on the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and is used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Sequoia is intended to update the primary bundle via a CloudKit connection to iCloud, although it can still update the secondary bundle using those released via Software Update when they’re available. This is expected to be updated every two weeks, but may not be the same as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, and that will also copy an update obtained through Software Update to the primary location.

Bastion
Latest version: not given, but bundled in the current XProtectPayloads.
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. As of XProtectPayloads 137 it has 12 Bastion rules, but doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated infrequently.

AppleKextExcludeList
Latest version: 20.0.0, 5 September 2024 (15.0 release).
This is a huge list of kernel extensions which are to be treated as exceptions to Sequoia’s security rules, and is stored on the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist.

Others

IncompatibleAppsList
Latest version: 140.191 (15.0 release).
This is a bundle on the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.

Vestigial Data

MRTConfigData
Latest version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored on the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but may be later as a security data update.

Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database on the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database is no longer used.

Gatekeeper E Configuration Data (GKE)
Latest version: 8.0.
This is an SQLite database on the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since.

Recently Removed

TCC_Compatibility Bundle
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/TCC_Compatibility.bundle which has been removed from Sequoia.

Core Services Application Configuration Data
This used to be a bundle on the System volume at /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle, containing a list of app exceptions in /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist. This has been removed from Sequoia.

CompatibilityNotificationData
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/CompatibilityNotificationData.bundle, containing CompatibilityNotificationData.plist, and listing version ranges of third-party products to be notified as being (in)compatible. This has been removed from Sequoia.

Last updated: 24 September 2024.

Apple silicon Macs are the first Apple computers to feature fully secure boot processes as one of their fundamental design goals. Although similar in some ways to those in Apple’s devices and in Intel Macs with T2 chips, there are substantial differences. Unlike T2 Macs, secure Boot in Apple silicon is maintained even when starting up from external storage, a feature completely unsupported by devices. Non-standard configurations are also available to give greater flexibility with reduced security modes, which are absent from devices. This article explains how to manage Secure Boot on Apple silicon Macs.

Full Security

By default, Apple silicon Macs start up in Full Security, the mode recommended by Apple for normal use. That requires:

• Following pre-boot stages, a Signed System Volume (SSV) is loaded from its snapshot, with its seal intact and signature verified.
• The only kernel extensions loaded during boot are those supplied by Apple in macOS. No third-party kernel extensions can be loaded.
• System Integrity Protection (SIP) is fully enabled.

Because they run outside the privileged space of the kernel and its extensions, third-party system extensions and their relatives can be loaded and used fully.

Booting in Full Security applies full control and verification of all components from the Boot ROM, through the Low-Level Bootloader (LLB) and iBoot ‘firmware’, to the kernel and its extensions in the SSV. If any part of that sequence fails to verify, the boot process is halted and, depending on where the failure has occured, the Mac is either put into DFU or Recovery mode for the user to address the problem. This not only ensures robust security throughout, but it also guards against potential conflicts such as those arising with third-party kernel extensions, and unintentional corruption of any component.

Changing security

Control over boot security is applied using Startup Security Utility when booted in paired Recovery (except in Big Sur, as explained below). Access this by starting the Mac up into normal paired Recovery with a single long hold of the Power button. When the first screen has loaded, click the Options button, then from the Utilities menu select the Startup Security Utility command.

You will then be prompted to select the boot volume group whose security policy will be set. Note that in macOS 12.0.1 and later this must be the same as that for the paired Recovery being used.

By default that will already be in Full Security. Set the new policy as explained below, and click the OK button. To apply that policy, select the Restart command to exit Recovery and start up in normal user mode.

Startup Security Utility changes the LocalPolicy settings for that boot volume group; those are stored in the iSCPreboot volume on the hidden Apple_APFS_ISC container on the internal SSD of that Mac. Full details of LocalPolicy are given in Apple’s Platform Security Guide, and explained here.

Big Sur is a notable exception to the requirement to change security settings in the paired Recovery volume: it doesn’t have a paired Recovery volume, but boots into Recovery from a hidden container on its internal SSD, from where Startup Security Utility controls security settings for all mounted boot volume groups.

Fallback Recovery (frOS) is unable to change LocalPolicy, thus Startup Security Utility is unavailable when booted in frOS, its most distinctive feature.

Although the bputil command tool gives access to security settings, its use to modify them is hazardous, and shouldn’t be attempted unless you know what you’re doing and are prepared to have to restore that Mac in DFU mode. It is, though, sometimes useful as an aid to solving problems with LocalPolicy settings, as explained here.

Reduced Security

When reducing security settings, the only other option available is Reduced Security, which forms the gateway to Permissive Security as well. There are two other common reasons for selecting Reduced Security, though: to enable the loading of third-party kernel extensions, and to run older versions of macOS.

To enable the loading of third-party kernel extensions, Reduced Security must be set, and the upper checkbox ticked. Once this has been applied by a restart, installation and loading of the kernel extension can proceed using its installer and Privacy & Security settings. That doesn’t enable loading of the kext on demand, as in the past, as it has to be merged into a signed Auxiliary Kernel Collection, from where it can loaded during startup.

Although Apple states that Reduced Security is required to run older versions of macOS, that doesn’t appear to be required at present. Reduced Security differs from Full Security in that LLB and iBoot trust ‘global’ signatures that are bundled with macOS rather than using personalised signatures for iBoot and beyond. For many, this may appear to be an insignificant reduction compared with Full Security, although it does add the risks of loading third-party kexts when used for that purpose.

Permissive Security

Startup Security Utility doesn’t offer Permissive Security as an option until Reduced Security has been selected and an action has been taken to downgrade that to Permissive Security. The most likely reason for doing this is to partially or completely disable SIP using csrutil, and once that has been performed this third setting is shown in Startup Security Utility.

Just as with Reduced Security, this offers two further options in checkboxes, including that to enable the loading of third-party kernel extensions.

The main reason for using Permissive Security is to reduce SIP settings, and I have recently provided a guide to the controls available in csrutil. The normal sequence for changing those is to start up in paired Recovery, open Startup Security Utility, set that to Reduced Security and click on the OK button. Following that, open Terminal, run the appropriate csrutil command, then restart the Mac, which will automatically be in Permissive Security.

The security effects of Permissive Security are determined largely by changes made to SIP and other controls. Although signatures are still validated throughout the chain of boot stages, ‘global’ signatures are trusted for iBoot and beyond, as are boot objects signed locally by the Secure Enclave. At its most extensive, this allows the use of a fully untrusted kernel, such as a debug or custom version. The penalty is that some decryption keys are no longer available, and those restrict features available in macOS, such as Apple Pay, which is normally disabled.

Reversing Permissive Security requires fully enabling SIP using csrutil, undoing any other relevant security settings, then using Startup Security Utility to set a higher level of security. In some cases, that may entail installing a fresh macOS with its SSV. Apple also notes that, on Apple silicon Macs, SIP settings aren’t stored in NVRAM but in the LocalPolicy.

External Boot Volumes

With the notable exception of Big Sur, boot security settings are saved into the LocalPolicy for the boot volume group containing that paired Recovery system, although all LocalPolicy settings are saved to the internal SSD, never to an external disk. This relies on the concept of ownership, as explained here. This can bring its own problems, as explored here.

Summary

• Unless there’s a good reason, leave boot volume groups in Apple silicon Macs in Full Security.
• If your Mac needs to load a third-party kernel extension, run it in Reduced Security with those kernel extensions enabled.
• Partially or completely disabling SIP requires Permissive Security, which brings significant penalties, and may require more extensive work to undo.
• Use Startup Security Utility rather than bputil.

Reference

Apple’s Platform Security Guide