It’s well known that M1 Macs offer three levels of boot policy:

• Full Security, which normally means a ‘proper’ installation of the same (or more recent) version of macOS as is on the internal SSD;
• Reduced Security, such as a ‘proper’ installation of an older version of Big Sur, such as 11.2.3, when the internal SSD is running 11.3.1;
• Permissive Security, which is anything else permitted, including custom builds of an XNU kernel.

If you enter RecoveryOS and open Startup Security Utility, though, you’re only offered the first two in its window. This article goes in quest of Permissive Security and why you don’t want to use it. Ever.

Apple drops us a clue or two in the latest, revised edition of its invaluable Platform Security Guide (which now also works in non-US English: hurrah!). There it states:
“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.”

So if you want to disable SIP on an M1 Mac, you have to downgrade that bootable disk to Permissive Security, and disabling SIP appears to be one way of doing that. Presumably other ways, such as unsealing macOS, are similar. For convenience, I explain this further in the Postscript below.

Apple does provide a command line tool for working with M1 boot policy: bputil, which perhaps should have been named morphine, as it’s powerful, extremely dangerous, potentially addictive, and ultimately could lead to self-destruction. A bit like Caravaggio too.

This impression is confirmed when you read bputil‘s man page. Its preamble reads:
“This utility is not meant for normal users or even sysadmins. It provides unabstracted access to capabilities which are normally handled for the user automatically when changing the security policy through GUIs such as the Startup Security Utility in macOS Recovery. It is possible to make your system security much weaker and therefore easier to compromise using this tool. This tool is not to be used in production environments. It is possible to render your system unbootable with this tool. It should only be used to understand how the security of Apple Silicon Macs works. Use at your own risk!”
Each time that you use bputil, you’re told exactly the same, before it does anything for you.

If you’re brave or foolish enough to read any further, you’ll discover that you specify the bootable OS using the APFS Volume Group UUID. So there doesn’t appear to be any way of slipping a version of macOS or any other operating system past M1 boot policy unless it runs from an APFS Volume Group. Among many other factors, this explains why you can’t (yet) boot an M1 Mac into any other operating system. It’s far simpler to run Linux or Windows in a virtual machine, as Parallels Desktop already does. Asahi Linux will be different, though, when it’s ready.

There is, though, one use for bputil which some advanced users will appreciate: the command
sudo bputil -d
in Terminal will provide intimate details of all currently recognised boot disks for that authorised user. You can use the same (without sudo) in Terminal in RecoveryOS.

If there’s more than one bootable macOS Volume Group available, bputil will invite you to select one from a list of UUIDs:
This computer has several macOS installations:
1: 6A516FF1-2AB9-45BD-941A-EEA5568570BF
2: CF3EE91B-D9F8-430C-B5B3-13886470F1FC
Pick a macOS installation (1..2):

There follows a long list of information about LocalPolicy for that installation, among which I draw attention to the following:

• Full Security enabled – when absent, this means that Full Security is in force;
• SIP enabled – when absent, this means that SIP is enabled;
• Signed System Volume enabled – when absent, this means that the SSV is intact and required for booting;
• Boot Args filtering enabled – when absent, this means that non-standard boot arguments aren’t allowed;
• 3rd party kexts disabled – when absent, this means that third-party kernel extensions aren’t permitted.

But whatever you do, you can rest assured that merely typing the characters bputil will instantly disable any support that your M1 Mac was signed up for. Damn, there goes my AppleCare again.

Postscript

Comments suggest that my explanation of Permissive Security above isn’t clear enough, so I’ll explain what I understand from Apple’s documentation.

While a user may opt for Reduced Security as a choice, perhaps so that they can run an older version of macOS or enable third-party kernel extensions, Permissive Security (PS) isn’t normally something you’d choose – it’s thrust upon you when you make other choices which aren’t compatible with either of the more normal security levels. To do so, you need to use a command tool whose consequences include the change of level.

One example of these, specifically given by Apple, is disabling SIP on a bootable disk. SIP is an essential part of both Full Security and Reduced Security, so should you turn SIP off using csrutil, macOS will automatically set that boot disk to PS for you. I presume that, as keeping the Bootable Volume Group sealed is another requirement of the two higher security levels, unsealing the system on a bootable disk also inevitably leads to its LocalPolicy being set to PS, although Apple doesn’t explain that.

So PS isn’t the choice that you’d be making in those cases, but a consequence of another choice, and before you could upgrade the security level you’d have to reverse the downgrade that you’d made to its security, for example by enabling SIP again. However, as you can’t re-seal an unsealed System, that appears to be a one-way street.

I hope that makes the situation (as I understand it) a little clearer. For users who might need to disable SIP to delete some protected files, which is a not uncommon reason, this appears to make the process even more daunting.