Secure boot support

[jasperweiss]

According the secure boot specification, users can enroll their own keys for secure boot.
If the QOS bootloader were signed, users could manually enroll the signing key within the UEFI. That would be a better anti evil maid system since it doesn't require the use of potentially untrusted USB keys.

Since dom0 doesn't contain any 3rd party applications, we can enforce code signing on anything that runs within it.

This blog post mentions secure boot being problematic due to running CA's etc but providing the user with a public key they can enroll manually would be doable.

Edit: I'm aware the developers are generally not very fond of secure boot. Could anyone explain why?
Alternatively a TPM could be used to unseal the drive encryption key.

Pre-OS firmware components are hashed (measured)
Measurements are initiated by startup firmware (Static CRTM)
Measurements are stored in a secure location (TPM PCRs)
Secrets (encryption keys) are encrypted by the TPM and bounded to
PCR measurements (sealed)
Can only be decrypted (unsealed) with same PCR measurements
stored in the TPM
This chain guarantees that firmware hasn’t been tampered with

[marmarek]

See this message the further down the thread. In short: just signing bootloader and/or Xen isn't enough, and would result in something trivial to bypass (for example using kernel parameters).

[jasperweiss]

@marmarek so the bootloader should check the next piece in the boot-chain as well as as all the parameters. Wouldn't it be possible to enforce code signing throughout dom0 similar to Windows 10S?

[marmarek]

Parameters are different for each installation, so you need to sign them yourself. Read that thread.

And BTW just setting up SecureBoot as a protection against someone with physical access (replacing /boot etc) isn't enough. One can simply disable SecureBoot and you'll most likely not notice. On some systems it might be non-trivial without a BIOS password (re-flashing BIOS etc), but still very much doable with physical access.
So, here SecureBoot guards only against very simple attacks. Note that SecureBoot makes much more sense on non-Qubes system, where compromising monolithic system is enough to replace boot files, without physical access.

On the other hand, AEM-like solution guard against this kind of attacks too, because it doesn't rely on BIOS to prevent the boot if something goes wrong. Instead, TPM will not release keys if you boot different binary. While there are different ways to bypass BIOS refusal to boot, you can't fake to the user data decryption if you don't have a key.

Anyway, those mechanisms are not excluding each other. Right now AEM is not compatible with UEFI, so getting either of them implemented would be an improvement.

[jasperweiss]

Indeed a TPM would be necessary to provide meaningful protection. It measures the UEFI firmware data, settings, secure boot state and provisioned signing keys prior to releasing (part of) the decryption key.

[marmarek]

Notes how kernel signing is done in Fedora build infrastructure:
kernel build log:

+ '[' -f arch/x86_64/boot/zImage.stub ']'
+ _pesign_nssdir=/etc/pki/pesign
+ '[' 'Red Hat Test Certificate' = 'Red Hat Test Certificate' ']'
+ _pesign_nssdir=/etc/pki/pesign-rh-test
+ '[' -x /usr/bin/pesign ']'
+ '[' x86_64 == x86_64 -o x86_64 == aarch64 ']'
+ '[' 0 -ge 7 -a -f /usr/bin/rpm-sign ']'
++ id -un
++ uname -m
+ '[' 'Fedora Project' == 'Fedora Project' -a mockbuild == mockbuild -a x86_64 == x86_64 ']'
+ grep -q ID=fedora /etc/os-release
+ [[ bkernel04.phx2.fedoraproject.org =~ ^bkernel.* ]]
+ '[' -S /var/run/pesign/socket ']'
+ '[' -S /var/run/pesign/socket ']'
+ /usr/bin/pesign-client -t 'Fedora Signer (OpenSC Card)' -c '/CN=Fedora Secure Boot Signer' -i arch/x86/boot/bzImage -o vmlinuz.signed -s
+ '[' '!' -s -o vmlinuz.signed ']'
+ '[' '!' -s vmlinuz.signed ']'
+ mv vmlinuz.signed arch/x86/boot/bzImage

PESign tool (including pesign-client): https://github.com/vathpela/pesign
Setup exposing pesign socket to kernel builders: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bkernel/tasks/main.yml?id=17198dadebf59d8090b7ed621bc8ab22152d2eb6
Mock config snippet mounting that socket inside build chroot:

# mount the pesign socket into the chroot
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign', '/var/run/pesign' ))
config_opts['plugin_conf']['package_state_enable'] = False

In short: kernel build environment is given access to the signing key through a bind-mounted unix socket. It may be doable to replicate similar setup in our build infrastructure (with appropriate logging what gets signed).

[osresearch]

As part of adding Qubes support to safeboot, I have a preliminary patch for Xen to build a unified xen.efi + xen.cfg + bzImage + initrd (and optional xsm), which can be signed with sbsigntool (including support for using a Yubikey or other PKCS#11 token to store the private key). osresearch/xen@765f0fe

With this modification there is no need for grub -- the UEFI firmware can validate the signature on the hypervisor bundle using the SecureBoot PK/KEK/db key chain and directly invoke it if-and-only-if the signature is valid. Although, as @marmarek pointed out in #4371 (comment), it is also necessary to use a TPM sealed secret that includes the platform key and secure boot DB to be able to prevent a local attacker from reflashing with Secure Boot disabled. The tpm2-attest part of safeboot can likely be ported to dom0 for remotely attesting this, although I haven't gotten that far yet in the Qubes support.

[marmarek]

Thanks, this looks very promising!

I have two main issues with using xen.efi in general:

1. Other boot files (dom0 kernel, initrd) loading by xen.efi is very unreliable - depending how xen.efi got started and/or specific UEFI implementation the required File System Protocol Interface may be missing or unable to access those files (including limitations like supporting ESP only, which on ISO9660 is limited to 32MB - pretty tight for installation initrd). Bundling everything into xen.efi may help partially here.
2. It is quite cumbersome to modify anything about boot parameters (even things like "choose older kernel") without grub (or other bootloader with interactive menu). If you want to modify dom0 boot options, you need a file editor (grub at this point is not enough). This is especially painful if your system fails to boot - you need then external boot media to perform any kind of troubleshooting/recovery. Embedding boot files into xen.efi makes this process even harder. But you can have multiple files with different versions embedded (allows you to boot different version, but not modify boot parameters even if you temporarily disable SecureBoot).

Those two are UX and stability related issues, not necessary security related. But for anything to be considered into default installation, those are also very important. Although for non-default, for power-users only solution those are less critical.

As for security concerns mentioned earlier in this thread, I understand your approach requires each installation to use unique, user-owned keys to sign boot files and have them included into secure boot DB, right? With this assumption it should be fine. Just to be sure I haven't missed anything - there is no way to stretch this approach into something compatible with standard secure boot DB keys (MS-signed shim), right?

[osresearch]

Bundling definitely avoids having to figure out the file system APIs and also makes it possible to embed in a ROM firmware volume, if you're lucky enough to have that option.

Choosing between versions can be done with the UEFI boot manager, although this doesn't allow changing parameters.

Modifying the boot parameters is challenging, although that is somewhat intentional - since the kernel parameters and xen config are critical to security, allowing arbitrary changes by a local user/attacker is dangerous. On the (non-Qubes) safeboot systems, the configuration is to have separate EFI boot manager entries for linux, the signed+sealed+dmverity-protected system, and recovery, the signed kernel with write access, but without access to TPM sealed secrets. An administrator with access to the disk recovery key can boot into the recovery kernel, unlock with disk, install new packages, upgrade kernels, edit the linux command line, etc. Once the system has been repaired, they hash the filesystem and build a new unified Linux/initrd/etc and sign it with a hardware token. This single file goes into the ESP and replaces the existing linux target. They also pre-compute the hash of the unified image and sign a PCR policy that allows the TPM to unseal the disk encryption key when that kernel is booted.

This does require a bit more space on the ESP since the recovery and normal kernel can't share bzImage or initrd files, although that hasn't yet been a problem for the machines I've configured.

[osresearch]

For the general use case, it might be workable to have the install image signed with the distribution key and to have that key signed by Microsoft so that the installer can boot. If they don't change the defaults, they can continue to use the official kernel, initrd and config as signed by the Qubes key.

If they do want to use their own keys, perhaps during the setup the user could be prompted to setup a software or hardware key and point them towards the steps for enrolling these keys in their firmware. Then they would need to use to sign any new kernels or initrd images that they build for the dom0, as well as any xen upgrades. With safeboot it isn't seamless right now; you can boot into recovery, install updates, and then have to run a separate command to re-sign everything. This would likely only be beneficial for very