Sign boot images #8206
Labels
C: builder
Qubes Builder
C: Xen
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
security
This issue pertains to the security of Qubes OS.
Comments
marmarek
added
T: enhancement
C: builder
andrewdavidwong
added
the
security
I think this might be a typo. 😅 To help me (and others) better understand this issue, could we make the problem being addressed more explicit?
This is useful to differentiate this issue from other issues, but it's still not entirely clear to me what the value prop is. My general guess is improved security, but I'm not entirely clear on exactly which forms of attack this is designed to mitigate (and which it is not), for example. |
This on its own, prevents modifications of grub, xen and linux kernel in /boot, as long as the attacker cannot modify UEFI (either the binary itself, or its settings to disable SecureBoot or add their own key).
|
|
Specific steps in this ticket:
|
|
Why use GRUB instead of systemd-boot? GRUB has a history of security holes that it takes a long time to fix.
Is this necessary for secure boot to be meaningful? |
I don't think it's relevant in this ticket at all, especially since for systemd-boot you'd need unified binary too.
Depending on what you want to achieve. If just compliance with MS requirements, probably not. But if using UEFI SecureBoot to protect system boot against malicious modifications of boot process, then yes, otherwise one could sneak for example |
No Xen patch should be necessary: the command line to |
|
An attempt from today's laboratory session.
I left this out as of today, since to make our desired chain work as intended with UEFI Secure Boot, the shim_lock protocol has to be present. Otherwise the error message
I initially tried to handcraft a unified image with @DemiMarie's uki-generate script to make sure it works fine before diving deeper into creating the whole infrastructure for a build process. Here's a brief description of what I did:
(The
Unfortunately, the last point is where I got kind of lost. It seems like during this boot process, So I ran dmesgxl dmesgDid I do something wrong? Maybe this approach is incorrect and I should have prepared the chain in the form of a shim binary with an embedded CA, then signed the GRUB2 and the Xen UKI binaries with the keys related to that CA? |
marmarek
added a commit
to marmarek/qubes-core-admin-linux
that referenced
this issue
Nov 16, 2023
They don't have any secrets, and having them root-only breaks building initramfs as non-root. QubesOS/qubes-issues#8206
marmarek
added a commit
to marmarek/qubes-core-admin-linux
that referenced
this issue
Nov 24, 2023
They don't have any secrets (the file is publicly available in git repository and rpm package), and having them root-only breaks building initramfs as non-root. Add -P option to usbguard-daemon to skip config file permission check. QubesOS/qubes-issues#8206
fepitre
added a commit
to fepitre/qubes-core-agent-linux
that referenced
this issue
Dec 2, 2023
Related to QubesOS/qubes-issues#8206
|
Last week I did some work regarding shim-unsigned for Qubes OS, so GRUB2 works fine with the shim_lock protocol. Please fork my qubes-shim-unsigned repository, add the Qubes CA certificate there (I named it I've checked with a laboratory certificate and the building process should work - I've checked with my fork of qubes-builderv2. I'm not creating a PR yet, as I suppose the qubes-shim-unsigned repo as a source of truth will be coming from QubesOS/qubes-shim-unsigned, rather than from my GitHub account. Once it's there, then I'll change the reference in the .yml file and request a PR. |
fepitre
added a commit
to fepitre/qubes-builderv2
that referenced
this issue
Dec 10, 2023
Related to QubesOS/qubes-issues#8206
|
Managed to also boot to QubesOS. I used and used Without SB booting uki via GRUB works. Added to With SB (after also signing grub EFI file) I get: Booting directly via BIOS (Add boot file option) works. I can login to Qubes and dmesg shows |
|
@m-iwanicki It seems to be the same thing I saw here: #4371 (comment) @marmarek, we achieved Xen uki, as discussed in #4371. I understand that the choice was to go with signing Qubes Shim by Microsoft, but as you know, we would also like to see support for an alternative path. One which is very easy is including the CA you posted above in Dasharo firmware and allow hardware platforms with Dasharo and UEFI Secure Boot enabled to install/boot Qubes OS. The second could be baking our installer with components signed by a key enrolled in the system. The third could be signing existing components in the installed system, rebooting, enrolling keys, and enabling UEFI SB. To test the first one, some binaries published by the Qubes OS Team must be signed with the posted CA. The second and third approaches also seem viable, thanks to confirming that xen uki boots are in qemu. Is this correct thinking? What would be the next logical step forward toward achieving the above goals? If the discussion should be continued in another issue, please let me know. |
|
@pietrushnic @marmarek UEFI supports multiple signatures of the same file, and I recommend that Qubes OS take this route. Specifically, the same UKI should be usable on both systems that only trust ITL’s CA (now) and that only trust Microsoft’s third party CA (once Xen is ready and the shim review process is finished). The recommendation should be to use ITL’s CA. |
|
@DemiMarie, where to find ITL CA? What Marek posted is I think three cases are valid:
|
Do you have a source for this claim? My current state of knowledge says the opposite, that this is in practice not actually possible to use: See comment 2 in https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1895817
I think Demi meant that one. (Don't bake this cert into anything productive yet, we are currently reviewing it.) Based on looking at other shim-review processes there's no need to include the formal legal entity into that CA name, so naming it just "Qubes OS" makes much more sense.
Once Xen can fulfill the requirements that would be nice to have as "hardware enablement" (as in: it just boots without having to fiddle with firmware settings).
I think we want to support that too. While that would be a bit nicer, I think multi-signatures aren't actually needed here. What we can do here is: MS's third-party CA trusted by firmware (doesn't matter if firmware trusts Qubes CA or not): MS's third-party CA not trusted by firmware, but Qubes CA trusted: [*]: "Qubes" refers to whatever part of Qubes (excluding shim) is loaded first. Might be a UKI, or a secure boot enabled grub, or whatever. So our installer/packaging would need to support to generate a proper ESP with and without shim. (Implementation details will need further thoughts, but from a user perspective might be as easy as install/remove
Test build should not be signed by the real CA. Once that gets backed into shim or firmwares, everything that will or has been signed by it needs to be reviewed if it still fulfill secure boot requirements and if not it needs to be revoked which is not easy. For early testing it's probably easiest if you just generate a test CA locally. Once the infrastructure work on our side is done we will need to have a test CA anyway, so that can be used too then. |
|
We have test infra already, PR QubesOS/qubes-vmm-xen-unified#1 uses it. You can download test-signed binary from CI artifacts: https://gitlab.com/QubesOS/qubes-vmm-xen-unified/-/jobs/8829912966/artifacts/browse/artifacts/repository/host-fc41/vmm-xen-unified_4.19.1r2+6.12.5r2/ (I believe the cert is included in the signed binary so you can extract it from there). |
I'd prefer to have the same boot flow in both cases, which probably means alternative shim packages, instead of having it or not. |
In this specific case that's true. For chains with intermediate certificates that's not necessarily true.
Probably a good idea. |
Valid point. This adds an unnecessary step in the verification chain for the with-QubesCA case, but makes both cases more similar. We could use the very same build of shim in both cases. Just once sign it through our CA and once through MS. The other option (IIUC) is to use a build of shim without any included CA. Since the Qubes CA is already in the UEFI list of trusted CAs in that case it will still load our UKI/grub. The later would have the advantage that if someone wants to use their own CAs they just need to resign our binaries without having to modify the CA included in the shim. |
Yes, I had to:
# get grub modules
wget https://ftp.qubes-os.org/repo/yum/r4.2/current-testing/dom0/fc37/rpm/grub2-efi-x64-modules-2.06-4.fc37.noarch.rpm
rpm2cpio grub2-efi-x64-modules-2.06-4.fc37.noarch.rpm | cpio -imvd
# create SBAT.csv. Copied from grubx64.efi on Fedora (40) installation with working SB
cat <<EOF >sbat.csv
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,3,Free Software Foundation,grub,2.06,https//www.gnu.org/software/grub/
EOF
# build grubx64.efi.
GRUB_MODULES="all_video increment boot btrfs multiboot multiboot2 cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label serial sleep smbios squash4 test tpm true video xfs zfs zfscrypt zfsinfo cpuid play cryptodisk gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool luks lvm mdraid09 mdraid1x raid5rec raid6rec"
# Works in bash. Use ${=GRUB_MODULES} in zsh.
grub2-mkimage -d usr/lib/grub/x86_64-efi -o grubx64.efi -O x86_64-efi -p / --sbat sbat.csv ${GRUB_MODULES}
# build shim
openssl req -new -x509 -newkey rsa:2048 -nodes -keyout shim.key -out shim.crt -subj "/C=PL"
openssl x509 -in shim.crt -out shim.cer -outform DER
git clone --recurse-submodules https://github.com/rhboot/shim.git
cd shim && make VENDOR_CERT_FILE=../shim.cer && cd ..
# sign everything
sbsign --key DB.key --cert DB.crt --output grubx64.efi grubx64.efi
sbsign --key DB.key --cert DB.crt --output shimx64.efi shim/shimx64.efi
sbsign --key DB.key --cert DB.crt --output mmx64.efi shim/mmx64.efi
# Copy everything to EFI partition
sudo losetup --show -Pf qubes.img
sudo mount /dev/loop0p1 efi
sudo cp shimx64.efi efi/EFI/BOOT/BOOTX64.EFI
sudo cp mmx64.efi efi/EFI/BOOT/mmx64.efi
sudo cp grubx64.efi efi/EFI/BOOT/grubx64.efi
sudo cp efi/EFI/qubes/grub.cfg efi/EFI/BOOT/grub.cfg
sudo umount efi
sudo losetup -d /dev/loop0p1After that you should be able to enter GRUB and boot signed xen UKI file e.g. from GRUB cmdline: chainloader /efi/qubes/uki-xen.efi
boot |
|
And to pass cmdline with chainloader I had to use |
Yes, this is already implemented at https://github.com/QubesOS/qubes-vmm-xen-unified/blob/main/25_unified_xen_linux |
Thanks @HW42, considering @marmarek comment I think we should perform test which would be as close to production as possible. It would slowly move state of the UEFI SB forward. So @marmarek if you could extend the chain and test-sign qubes-vmm-xen-unified so @m-iwanicki could install it on real Dasharo supported hardware and we could confirm that configuration works. Also I wonder how advanced user/developer could create chain for themselves, We would like to have guides regarding that published. This would be part of training as well as presentations about UEFI SB ecosystem we plan to give this and following years. @m-iwanicki I would envision creation and contribution of such materials (including cases of installing certificates discussed above) wherever Qubes OS Team see it as most suitable place (official docs, community forum, Dasharo docs?). @marmarek I see it as giving good example to other Xen distributions on to the rest of the ecosystem since current perception is MSFT signed-shim which IMHO is not the best approach. It would be great if we could present some preliminary decision about deliverables during Xen Winter Summit talk.
@HW42 agree. Key question for me is where Xen effort is coordinated? Who is working on which piece? TBH I can't find single place. Effort and discussion is spread across downstream communities (Qubes OS, XCP-ng), some brief explanation by @andyhhp during community call, couple presentation and discussion on matrix. During Qubes OS Summit @andyhhp mention fixes in Xen are needed for MSFT signing, but potential of breaking chain of trust which concerns MSFT is also concerning for community. Here good question would be if Qubes OS Team plan to release anything in production before Xen upsteam address all MSFT requirements? Considering lack of visbile activity in Xen (I may be wrong here) this may take very long (years?). Our hope is that correct scoping and coordination could lead to faster resolution or at least steady progress in implementing UEFI SB support in Xen.
Great. This is precisely what we looking for.
Ok, I guess that boils down to some documentation discussed above and letting community know how it was done. I may be wrong here, but my thinking is that having Xen UKI signed shipped, even without fulfilling all MSFT signing requirements, is better than shipping system which cannot be installed with UEFI Secure Boot enabled. What can be done to make it real at least for some advanced users/developers or some hardware (e.g. Dasharo supported) ? |
Official support for Secure Boot in Xen requires eliminating |
It does not answer my questions. Of course, it requires eliminating |
|
Making Xen compatible with Microsoft requirements for SB is being coordinated and developed by XenServer. I'm in no position to share any timelines about their work, but given the amount of changes needed, it will take some time, so it definitely not going to happen for R4.3. Anyway, that doesn't block any other related work, for the time being we'll "just" need to enroll qubes key into the firmware before enabling SB. |
Ok. Thanks for making it clear. I will try to get some timeline from them. Meanwhile, I asked a question on Citrix Forum since I can't see a better official way to contact them.
Does this also mean that we could enroll the Qubes key into Dasharo so Qubes can be installed out of the box on supported hardware? |
Yes, once we publish the certificate as the official one (we'll commit it into qubes-secpack repo). It is likely going to be the one pasted above, but please wait for the final confirmation before baking it into official firmware. |
@marmarek, why do we use GRUB? Shouldn't we be able to kick UKI directly from shim? @m-iwanicki can we try to kick uki-xen.efi directly from shim and see if it works? |
|
Technically, we don't have to use GRUB. But there should be a possibility to select alternative boot option (older kernel? or maybe adding Anyway, this is getting offtopic a bit. |
|
This is borderline out of scope because it partially covers |
|
@krystian-hebel The approach taken by systemd-boot is to provide a selection of command lines that the user can use. When secure boot is disabled, other command lines are allowed, but with secure boot enabled, they are ignored. A better approach would be to have an alternate command line that is passed to the system even with secure boot enabled, but which is treated as not trusted. However, I don’t know any way to implement that yet. |
@pietrushnic it doesn't. Fails with: Also tried with |
This seems like a bug. Which code is it a bug in? |
2 tasks
|
@m-iwanicki can you answer to @DemiMarie question? Meanwhile, |
|
I'm not sure, possibly in XEN. Someone with more experience should probably debug this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How to file a helpful issue
The problem you're addressing (if any)
"UEFI Secure Boot" support will require several changes in the system. This ticket is a subtask about changes to the packaging.
The solution you'd like
module2command.Ship all of the above as separate package(s), alternative to default boot packages. They may conflict with standard ones (forcing replacing them), or co-exist under different file names. The latter is probably friendlier to the user.
The value to a user, and who that user might be
This ticket is NOT about full UEFI Secure Boot support (for that we have #4371). It is only about preparing initial build and configuration infrastructure for it.
The text was updated successfully, but these errors were encountered: