safeboot intends to protect the integrity of the boot process and
runtime integrity of the system against adversaries with external physical
access to the device, as well as limited internal physical access.
The assumption is that the attacker can get code execution on the device
as the user and as root, but does not have access to the signing keys
or the disk encryption key. The goal is to prevent the attacker from
exfiltrating data from the device or making persistent changes to the
system configuration.
More details are in the threat model page.
safeboot is not a replacement for UEFI SecureBoot - the two work together to
improve the security of the system. SecureBoot ensures that the boot firmware is
measured into the TPM and validates the signatures on the Linux kernel and initrd,
and safeboot adds additional integrity protections beyond that.
The default UEFI Secure Boot configuration is sufficient for Microsoft's needs since they are the only signing authority for their runtime, while Linux computer owners frequently want to compile their own kernel or runtime. The compromise solution developed by Linux distributions has Microsoft sign a "shim" bootloader that has its own key management. Since most distributions have their keys enrolled in the shim, systems that have Secure Boot enabled will boot the distribution's ISOs, which might not be desirable since it potentially gives an adversary runtime access to unencrypted parts of the system.
A larger problem is that by default only the Linux kernel is signed,
not the command line parameters or initrd. While the grub bootloader
can enable a password to protect against casual changes to the kernel
parameters, the grub.cfg configuration is not typically signed. This means
that potentially a local attacker can modify it on disk to launch the
kernel with init=/bin/sh to drop into a shell, or an attacker with
root access can add trojan'ed binaries to the initrd to gain persistence.
By replacing the Platform Key and removing grub, only Linux kernel and
initrd images signed by the computer owner will boot.
Far more details on how safeboot extends UEFI SecureBoot are on
the threat model page.
BootHole (CVE-2020-10713),
is a vulnerability found and described by Eclypsium)
in grub's configuration file parsing which allows arbitrary code execution in grub even when Secure Boot is enabled.
Kelly Shortridge has a good writeup by at capsule8
that explains how this threat could be leveraged by an attacker and the difficulties in doing so in
a general case, although an attacker with physical access is able to write to the internal
disk and could launch this attack. Since these sorts of physical attacks are included
in the safeboot threat model, it is worth considering.
However, a system using safeboot is not vulnerable to CVE-2020-10713 since
grub is not used at all and will not be run even if it is present on the disk.
During the safeboot installation process, the system owner
replaces the UEFI Platform Key with their own,
which prevents the Microsoft signed shim used by grub from being loaded, and
they then create efibootmgr entries for linux and recovery
that are signed with their (hardware protected) key.
Assuming there are not vulnerabilities in the system's UEFI firmware or CPU vendor's BootGuard
(which may not be the best assumption...), the safeboot configuration should ensure
that only signed kernel, initrd, and command lines will be booted by the system.
This static chain of trust
helps prevent attacks on grub like BootHole, or other ones that modify on-disk
data, from being able to gain persistence or code execution.
One caveat to the protection provided by the UEFI Secure Boot Platform Keys is that
the UEFI NVRAM configuration data is stored in the SPI flash and is also subject to
modifications by a physically proximate attacker with internal access to the hardware.
However, if the attacker uses a flash programmer to change the Platform Keys in the flash,
the TPM measurements of the Setup variable will be different and the TPM should refuse
to unseal the disk encryption key since the PCR values will not match the sealed ones.
The adversary might try to roll back to an vulnerable version of the kernel and the
earlier signed PCRs, but the TPM will refuse to unseal since monotonic counter value
will not match the signed one.
An adversary might create a fake PIN entry screen to try to harvest the unsealing PIN or the recovery key, although in any of these cases, the TPM TOTP six-digit authenicator value will not be correct since the TPM will not unseal it with modified firmware. Additionally the system should fail remote attestation if it attempts to connect to a server that validates the TPM quote, improving platform resiliency even when attackers do gain persistence.
coreboot is entirely free software and can provide far better control of the boot process, although it is not supported on as many modern platforms as UEFI SecureBoot and requires reprogramming the SPI flash on the device. If you have a machine that supports both coreboot and Bootguard, then you're probably better off running it instead. However, be prepared to spend quite a bit of quality time with your SPI flash programmer to get it working...
Once coreboot or UEFI hand off to the Linux kernel, the TPM unsealing of the disk encryption key, the dmverity protections on the root filesystem and the lockdown patches work the same.
It has only been tested on the Intel systems with Bootguard. The UEFI platform keys and the rest of the lock down should work with AMD, although AMD's hardware secured boot process hasn't been reviewed as extensively as Intel's ME and Bootguard.
For an indepth analysis of the AMD Platform Support Processor (PSP) and SEV, Buhren, Eichner and Werling's 35c3 presentation is the most detailed look so far.
Qubes, a reasonably secure OS, uses the Xen hypervisor to separate device drivers and applications into separate virtual machines so that an exploit against an individual component doesn't necessarily compromise the entire machine. Unfortunately Xen's EFI support is not commonly used, and as a result running Qubes typically requires Legacy BIOS and turning off Secure Boot.
Adding Secure Boot support to Xen is possible with some patches (safeboot-issue #21), although it is a work in progress. There are other factors involved in configuring Qubes to use dm-verity and TPM sealed secrets that have not been addressed yet, as well as an open qubes-issue on distribution signing keys.
The TPM will only unseal the disk encryption key if:
- The policy is signed by the UEFI platform key.
- The PCRs in
$PCRSmatch the ones computed by the TPM, which typically include the firmware, UEFI setup variable, UEFI key database, and the PE hash of the kernel + initrd. - The boot mode PCR in
$BOOTMODE_PCRmatches the sha256 hash of thesafeboot.mode=kernel command line parameter and has not been extended post-boot. - The TPM monotonic counter in
$TPM_NV_VERSIONmatches the one in the policy. - The user PIN matches the on used to seal the data.
These requirements are violated by several different attacks, although
they can also fail if a new kernel is installed with safeboot linux-sign
and safeboot pcrs-sign was not successful. Typically kernel updates can be
handled seamlessly since the PCR4 value can be predicted from the PE hash of the
new kernel and initrd.
The PCRs will also be different when the system has had a firmware update
from fwupd (usually measured into PCR0), or if
the UEFI configuration is changed by the administrator (usually measured
into PCR1 and PCR5).
In both of these cases it is hard to predict what
the resulting PCR values will be, so it is typically necessary to reboot
into the recovery target to extend the PCRs with the new measurements
and then update the PCR policy with the new values by running safeboot pcrs-sign. Some vendors publish the new PCR0 values, and it might be possible
to predict it by evaluating the TPM event log, but it is not guaranteed.
For a fleet of identical systems, however, it is usually possible to do this upgrade on one offline machine and then distribute the signed kernel along with the signed PCR policy to the other machines. This requires some additional work to make practical, since the TPM counters are not synchronized.
safeboot's System Integrity Protection (SIP) is inspired by the
read-only filesystems of macOS SIP.
Like macOS, writing to the protected filesystems requires rebooting
with a special kernel command line parameter (in this case tpm.mode=recovery)
to enable write access.
Unlike macOS, safeboot SIP can not unseal the disk encryption keys
automatically from the TPM since the boot mode is part of the PCR
measurements, so knowledge of the disk recovery password is required.
This prevents a local adversary who escalates to root from being able
to disable SIP and reboot into a writable filesystem to try to gain
persistence.
safeboot's SIP is also inspired by the Android Verified Boot
that protects Android's /system partition. Like Android, safeboot SIP
provides cryptographic protection against an adversary who gains
write access to the filesystem since entire filesystem is protected
by the dmverity merkle tree of hashes. The root hash is signed by
the system owner as part of exiting recovery mode, and this root
hash is passed into the kernel on the command line.
The kernel command line is part of the cryptographic chain of trust
from the CPU boostrap through the Bootguard ACM, into the UEFI firmware,
and all the way to the Linux kernel and initrd.
This is potentially even stronger protection than macOS SIP since it provides protection even against an adversary with physical access, the root password and the disk recovery key. They can't sign the root hash without the hardware token, and if they change the signing keys in the firmare, then the TPM will no longer unseal the disk encryption key. They could re-seal the key with the new PCRs from their fake platform key, but the system would then fail both the TPM TOTP local attestation as well as the remote attestation when it tried to prove to an external system that it was in a trusted state.
With SIP enabled it is not possible to modify the root filesystem.
You must reboot into recovery mode with safeboot recovery-reboot
and decrypt the disk with the recovery password. Once decrypted,
you can run safeboot remount to unlock the raw device and remount
it rw. After making modifications, it is necessary to sign
the new root hashes with safeboot linux-sign.
There is probably a way to sign a new PK with the old PK, but I haven't figured it out... Instead here are the steps:
- Put the UEFI SecureBoot firmware back in
Setup Mode - Boot into the recovery kernel
safeboot remountto get write-access to the disksafeboot key-initorsafeboot yubikey-initto build a new key. Answer "y" to overwrite the existing one in/etc/safeboot/cert.pem.safeboot uefi-sign-keysto upload it into the firmwaresafeboot recover-signsafeboot linux-sign, which should re-generate the dmverity hashes- Reboot into the normal kernel
safeboot luks-sealto measure the new PCRs and normal kernel into the TPM
The best solution is to authenticate with the supervisor password to the UEFI Setup, re-enter SecureBoot setup mode and clear the key database, then boot into recovery mode and follow the instructions for switching to a new signing key. If you don't have the UEFI Supervisor password, well, then you're in trouble.
On modern Thinkpads the UEFI password is in the EC, not in the SPI flash. Lenovo does a mainboard swap to reset it; you could find a EC bypass(Matrosov 2019) or perhaps a Bootguard bypass(Bosch & Hudson, 2019) to get into Setup in that case.
Matrosov's 2019 BlackHat Talk is a deep dive into the Lenovo EC and why it is not as much of a protection boundary as some vendors think it is.
Unfortunately the wonderful butterfly keyboard Thinkpad predates UEFI by a few years, so it does not have a very secure boot process. The X1 Carbon is a much nicer replacement in nearly every way, other than missing the amazing sliding keyboard mechanism.
Please file an issue! Or submit a pull-request!