Last week, Mr. Macintosh gave a great presentation on the changes introduced with macOS Big Sur on M1 Macs for reinstalling macOS. Click here for the recorded presentation and here for the presentation slides. Having recently begun testing an M1 MacBook Air myself, I was very interested in getting a jump start on this.
There were a number of important takeaways from the presentation, but one in particular I learned was that M1 Macs no longer support the firmware password feature. Sure enough, reviewing Apple’s own support article on firmware passwords:
Having previously worked at a school, setting a firmware password was a critical security feature as it prevented anyone without this password from booting to anything other than the configured default boot volume. This ensured more tech-savvy users could not load their own bootable macOS from the organization’s hardware or boot to the recovery OS and potentially wipe the device entirely.
While Apple indicates in their support article that FileVault achieves the equivalent level of security, the question is even with FileVault enabled does this open up the ability for users to do mischief?
- On Intel Macs, the only security mechanism that prevents an admin user from booting to a different OS or the recovery OS is a configured firmware password.
- In Big Sur, external booting of validly signed macOS installers and macOS boot volumes is now permitted by default.
- Given M1 Macs do not have a firmware password option, any user with valid admin credentials can load macOS installers, other bootable macOS volumes, as well as fully erase and reinstall macOS.
- So long as your users are not admins, Apple’s claim of FileVault being an equivalent level of security is valid… but only in this context.
For more info, see past the jump.
For those who may have not used a Firmware password previously, this can be set (and removed) via the
firmwarepasswd command line tool with administrative privileges. This can also be set via the Firmware Password utility within the recovery OS.
When set, if you hold down the Option key or some other key combination to get the boot picker or other OS, you would be presented with a lock icon and a password prompt.
If you enter the correct firmware password this would then load the desired boot picker or boot option given the key combination. Without this password you could not boot from anything other than the default boot volume.
The benefit of this feature, besides the fact it locks the system to your desired boot volume is that it gives system administrators a way to prevent end users on the Mac who are also admins from changing the loaded OS volume or even load the recovery OS.
As has been the case for years now prior to the release of M1 Macs, Apple’s T2 security chip built in to Macs provides hardware-level security that in conjunction with FileVault prevent any user account without a Secure Token from getting past the FileVault login window and/or unlocking the volume to access any data on the device.
While security-wise this is all well and good, prior to macOS Catalina, environments with Macs that were used by multiple users / mobile accounts had the problem that users were not subsequently granted a Secure Token. In macOS Catalina
10.15.4, Apple introduced the Bootstrap token to help grant a secure token to any user logging in to a Mac, local users as well as mobile accounts, so long as the Mac was supervised and the feature was supported by the MDM vendor. This has since expanded in macOS Big Sur on M1 Macs managed by an MDM to authorize the install of kernel extensions and software updates.
Additionally with T2 Macs, Apple disabled the ability to boot from volumes not protected by the T2 chip by default. This required admins who used external media for OS reinstalls to first disable this setting from the Startup Security Utility in the recovery OS.
If left enabled however, this setting can only be changed by an admin user in the recovery OS, and as a result a configured firmware password would restrict end user admins from doing this.
Interestingly, this has actually changed in Big Sur where external booting of both validly signed macOS installers and macOS external boot volumes is now permitted by default. The only caveat here is while an external macOS bootable volume may be validly signed, since M1 Macs came with Big Sur preinstalled it cannot load an older OS.
Returning to the larger question though, is the removal of the firmware password security option for M1 Macs a major problem or a non-issue? To answer this, we have to explore:
- How someone could load an OS on a Mac other than the default bootable volume
- How someone could erase / wipe and reinstall macOS
On macOS Catalina, the following is experienced as a local admin user when attempting to boot to the recovery OS when a Mac is:
- FileVault encrypted
- Firmware password protected
- External OS / device booting is restricted
- Mac is started / rebooted, holding down Option or recovery OS key combination after POST chime.
- Firmware password prompt is displayed.
- With correct firmware password, boot picker is displayed.
- With external boot restriction enabled (default), can only select local disk bootable volumes or press key combination for recovery OS.
- In recovery OS, admin users on the Mac is displayed to authenticate to access recovery options.
- If no admin credentials are known, an option to provide the FileVault recovery key is available.
- Once authenticated as an admin or with recovery key, all recovery options are available including erasing the internal disk and reinstalling a new OS.
Ultimately, the only element in this process that prevents an admin user from booting to a different OS or the recovery OS is a configured firmware password. So for environments where all or most of your users are admins, the firmware password is your only safety net. In environments that have yet to enable FileVault encryption (excluding physical exfiltration of the storage media on Intel Macs), I would argue firmware passwords are a must!
Given that M1 Macs do not have a firmware password option, any user with valid admin credentials can load macOS installers, other bootable macOS volumes so long as they are also running Big Sur, as well as fully erase and reinstall macOS.
But what if your users are not admins?
In my testing on an M1 Mac, while nothing prevents a standard user from booting to the recovery OS (this process is different on M1 Macs) with FileVault enabled a standard user with the Secure Token can’t authenticate as themselves to actually access the recovery OS options. This is reserved only for admin users. Even if the user were to select the ‘Forgot all passwords’ option, they would still need to provide the FileVault recovery key which presumably they don’t have. The following is the end user experience:
- Mac is started / rebooted, holding down option or recovery OS key combination after POST chime.
- User loads recovery OS.
- In recovery OS, only local admin users are listed for authentication. As such, the standard user is not able to proceed & access the recovery OS options.
In this way, so long as your users are not admins Apple’s claim of FileVault being an equivalent level of security is valid… but only in that context. We MacAdmins know full well that there are org VIPs, developers, and other constituents that require (and sometimes demand) admin rights. And so here we are yet again where Apple removes functionality that gave us as a greater level of control and security of our organization’s Mac devices to only have no equivalent alternative.
Schools and other environments who need to more strictly manage their Macs will likely feel the brunt of this change, especially if users are admins by default and you don’t have a config management tool to keep your Macs. Without the firmware password, FileVault is definitely a must, and for those that may have tried to avoid that leap this would appear to no longer be an option on Apple Silicon.
If the removal of the firmware password for M1 Macs is problem for you, I would strongly urge you to file a radar and contact your Apple rep.