Startup Disk security policy control for a Mac with Apple silicon

Overview

Unlike security policies on an Intel-based Mac, security policies on a Mac with Apple silicon are for each installed operating system. This means that multiple installed macOS instances with different versions and security policies are supported on the same Mac. For this reason, an operating system picker has been added to Startup Security Utility.

On a Mac with Apple silicon, System Security Utility indicates the overall user-configured security state of macOS, such as the booting of a kext or the configuration of System Integrity Protection (SIP). If changing a security setting would significantly degrade security or make the system easier to compromise, users must enter into recoveryOS by holding the power button (so that malware can’t trigger the signal, only a human with physical access can) to make the change. Because of this, an Apple silicon–based Mac also won’t require (or support) a firmware password — all critical changes are already gated by user authorisation. For more information on SIP, see System Integrity Protection.

Full Security and Reduced Security can be set using Startup Security Utility from recoveryOS. But Permissive Security can be accessed only from command-line tools for users who accept the risk of making their Mac much less secure.

Full Security policy

Full Security is the default and it behaves like iOS and iPadOS. At the time software is downloaded and prepared to install, rather than using the global signature that comes with the software, macOS contacts the same Apple signing server used for iOS and iPadOS and requests a fresh, “personalised” signature. A signature is personalised when it includes the Exclusive Chip Identification (ECID) — a unique ID specific to the Apple CPU in this case — as part of the signing request. The signature given back by the signing server is then unique and usable only by that particular Apple CPU. When the Full Security policy is in effect, the Boot ROM and LLB helps ensure that a given signature isn’t just signed by Apple but is signed for this specific Mac, essentially tying that version of macOS to that Mac.

Using an online signing server also provides better protection against rollback attacks than typical global signature approaches. In a global signing system, the security epoch could have rolled many times but a system that has never seen the latest firmware won’t know this. For example, a computer that currently believes it’s in security epoch 1 accepts software from security epoch 2, even if the current actual security epoch is 5. With an Apple silicon online signing system, the signing server can reject creating signatures for software that’s in anything except the latest security epoch.

Additionally, if an attacker discovers a vulnerability after a security epoch change, they can’t simply pick up the vulnerable software from a previous epoch off system A and apply it to system B in order to attack it. The fact that the vulnerable software from an older epoch was personalised to system A helps prevent it from being transferable and thereby being used to attack system B. All these mechanisms work together to provide much stronger guarantees that attackers can’t purposely place vulnerable software on a Mac to circumvent the protections provided by the latest software. But a user that’s in possession of an administrator username and password for the Mac can always choose the security policy that works best for their use cases.

Reduced Security policy

Reduced Security is similar to Medium Security behaviour on an Intel-based Mac with a T2 chip, in which a vendor (in this case, Apple) generates a digital signature for the code to assert it came from the vendor. This design helps prevent attackers from inserting unsigned code. Apple refers to this signature as a “global” signature because it can be used on any Mac, for any amount of time, for a Mac that currently has a Reduced Security policy set. Reduced security doesn’t itself provide protection against rollback attacks (although unauthorised operating system changes can result in user data being rendered inaccessible. For more information, see Kernel extensions in a Mac with Apple silicon.

In addition to enabling users to run older versions of macOS, Reduced Security is required for other actions that can put a user’s system security at risk, such as introducing third-party kernel extensions (kexts). Kexts have the same privileges as the kernel, and thus any vulnerabilities in third-party kexts can lead to full operating system compromise. This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon. Even when third-party kexts are enabled, they can’t be loaded into the kernel on demand. Instead, the kexts are merged into an Auxiliary Kernel Collection (AuxKC) — whose hash is stored in the LocalPolicy — and thus they require a restart. For more information about AuxKC generation, see Securely extending the kernel in macOS.

Permissive Security policy

Permissive Security is for users who accept the risk of putting their Mac into a much more insecure state. This mode differs from No Security mode on an Intel-based Mac with a T2 chip. With Permissive Security, signature verification is still performed along the entire secure boot chain, but setting the policy to Permissive signals to iBoot that it should accept locally Secure Enclave–signed boot objects, such as a user-generated Boot Kernel Collection built from a custom XNU kernel. This way, Permissive Security also provides an architectural capability for running an arbitrary “fully untrusted operating system” kernel. When a custom Boot Kernel Collection or fully untrusted operating system is loaded on the system, some decryption keys become unavailable. This is designed to prevent fully untrusted operating systems from accessing data from trusted operating systems.

There’s another way that Permissive Security differs from No Security on an Intel-based Mac with a T2 chip: it’s a prerequisite for some security downgrades that in the past have been independently controllable. Most notably, to disable System Integrity Protection (SIP) on a Mac with Apple silicon, a user must acknowledge that they’re putting the system into Permissive Security. This is required because disabling SIP has always put the system into a state that makes the kernel much easier to compromise. In particular, disabling SIP on a Mac with Apple silicon disables kext signature enforcement during AuxKC generation time, thus allowing any arbitrary kext to be loaded into kernel memory. Another improvement to SIP that’s been made on a Mac with Apple silicon is that the policy store has been moved out of NVRAM and into the LocalPolicy. So now, disabling SIP requires authentication by a user who has access to the LocalPolicy signing key from recoveryOS (reached by pressing and holding the power button). This makes it significantly more difficult for a software-only attacker, or even a physically present attacker, to disable SIP.

It isn’t possible to downgrade to Permissive Security from the Startup Security Utility app. Users can downgrade only by running command-line tools from Terminal in recoveryOS, such as csrutil (to disable SIP). After the user has downgraded, the fact that it’s occurred is reflected in Startup Security Utility, and so a user can easily set the security to a more secure mode.