systemd-based FDE in MicroOS / Tumbleweed
Hi, Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system. Today we announce that we supporting the full disk encryption (FDE) tools that systemd bring us via systemd-cryptenroll or cryptsetup. We extended the pcr-oracle to support new PCRs and the generation of authorized policies in JSON format for systemd With this we also propose a new architecture in the distribution that allows the enrollment of the TPM2 (with full measured boot attestation) and the FIDO2 key, using the already available systemd user tools. The MicroOS image[0] was also extended to show all this nice features working together. The long (sorry, maybe too long) explanation is in the news-o-o blog post[1], and the technical details are in the openSUSE Systemd-fde wiki page[2]. Feedback is more than welcome! ... also happy holidays, end of the year and beginning of 2024! [0] http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-k... [1] https://news.opensuse.org/2023/12/20/systemd-fde/ [2] https://en.opensuse.org/Systemd-fde
Tested with QEMU and works Den tors 21 dec. 2023 kl 12:47 skrev aplanas <aplanas@suse.de>:
Hi,
Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system.
Today we announce that we supporting the full disk encryption (FDE) tools that systemd bring us via systemd-cryptenroll or cryptsetup. We extended the pcr-oracle to support new PCRs and the generation of authorized policies in JSON format for systemd
With this we also propose a new architecture in the distribution that allows the enrollment of the TPM2 (with full measured boot attestation) and the FIDO2 key, using the already available systemd user tools.
The MicroOS image[0] was also extended to show all this nice features working together.
The long (sorry, maybe too long) explanation is in the news-o-o blog post[1], and the technical details are in the openSUSE Systemd-fde wiki page[2].
Feedback is more than welcome!
... also happy holidays, end of the year and beginning of 2024!
[0] http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-k... [1] https://news.opensuse.org/2023/12/20/systemd-fde/ [2] https://en.opensuse.org/Systemd-fde
On 21.12.2023 15:47, aplanas wrote:
The MicroOS image[0] was also extended to show all this nice features working together.
...
[0] http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-k...
What about self-install image? Will it also default to systemd-boot+FDE(+TPM)?
aplanas wrote:
Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system. [...] The MicroOS image[0] was also extended to show all this nice features working together.
Update: A Tumbleweed image with traditional writable root filesystem is available now too: http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minim... That one should be more convenient for development. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg)
Tested in virt-manager with qemu on a Dell XPS laptop and it worked as it should Den mån 15 jan. 2024 kl 15:55 skrev Ludwig Nussel <ludwig.nussel@suse.de>:
aplanas wrote:
Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system. [...] The MicroOS image[0] was also extended to show all this nice features working together.
Update: A Tumbleweed image with traditional writable root filesystem is available now too:
http://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-Minim...
That one should be more convenient for development.
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; HRB 36809 (AG Nürnberg)
On 21.12.2023 15:47, aplanas wrote:
Hi,
Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system.
Today we announce that we supporting the full disk encryption (FDE) tools that systemd bring us via systemd-cryptenroll or cryptsetup. We extended the pcr-oracle to support new PCRs and the generation of authorized policies in JSON format for systemd
With this we also propose a new architecture in the distribution that allows the enrollment of the TPM2 (with full measured boot attestation) and the FIDO2 key, using the already available systemd user tools.
The MicroOS image[0] was also extended to show all this nice features working together.
I had to manually enter LUKS password after "transactional-update dup" until I manually run "sdbootutil update-predictions". Is it expected?
On 2024-01-18 18:01, Andrei Borzenkov wrote:
On 21.12.2023 15:47, aplanas wrote:
Hi,
I had to manually enter LUKS password after "transactional-update dup" until I manually run "sdbootutil update-predictions". Is it expected?
No. That should be automatic. "sdbootutil" is called after the end of any transaction. Last week we fixed some bugs in pcr-oracle, dracut-pcr-signature and sdbootutil itself. I think that most of the fixes should be going into Factory now, but none is related with not calling sdbootutil after an upgrade.
On 18.01.2024 22:06, aplanas wrote:
On 2024-01-18 18:01, Andrei Borzenkov wrote:
On 21.12.2023 15:47, aplanas wrote:
Hi,
I had to manually enter LUKS password after "transactional-update dup" until I manually run "sdbootutil update-predictions". Is it expected?
No. That should be automatic. "sdbootutil" is called after the end of any transaction.
Last week we fixed some bugs in pcr-oracle, dracut-pcr-signature and sdbootutil itself. I think that most of the fixes should be going into Factory now, but none is related with not calling sdbootutil after an upgrade.
Well, every time there are significant changes I have to enter LUKS password on reboot until I run "sdbootutil update-predictions". Happened just now. I did check before reboot that /boot/efi/EFI/systemd/tpm2-pcr-public-key.pem and tpm2-pcr-signature.json had current timestamp which means sdbootutil has been called during update. But after I rebooted and run "sdbootutil update-predictions" I got entirely different signatures in signature.json file. So my best guess is that sdbootutil (or whatever does it) fails to *predict* the correct signatures and TPM2 unlock fails.
On 2024-02-10 06:27, Andrei Borzenkov wrote:
Well, every time there are significant changes I have to enter LUKS password on reboot until I run "sdbootutil update-predictions". Happened just now. I did check before reboot that /boot/efi/EFI/systemd/tpm2-pcr-public-key.pem and tpm2-pcr-signature.json had current timestamp which means sdbootutil has been called during update. But after I rebooted and run "sdbootutil update-predictions" I got entirely different signatures in signature.json file. So my best guess is that sdbootutil (or whatever does it) fails to *predict* the correct signatures and TPM2 unlock fails.
Indeed, that seems to be the case. I created this: https://bugzilla.opensuse.org/show_bug.cgi?id=1219807 to track this.
On 12/21/23 07:47, aplanas wrote:
Hi,
Some months ago we announced the support of systemd-boot in MicroOS and in Tumbleweed, using a new tool named sdbootutil, that help us to synchronize the boot loader entries with available snapshots in the system.
Today we announce that we supporting the full disk encryption (FDE) tools that systemd bring us via systemd-cryptenroll or cryptsetup. We extended the pcr-oracle to support new PCRs and the generation of authorized policies in JSON format for systemd
With this we also propose a new architecture in the distribution that allows the enrollment of the TPM2 (with full measured boot attestation) and the FIDO2 key, using the already available systemd user tools.
The MicroOS image[0] was also extended to show all this nice features working together.
The long (sorry, maybe too long) explanation is in the news-o-o blog post[1], and the technical details are in the openSUSE Systemd-fde wiki page[2].
Feedback is more than welcome!
... also happy holidays, end of the year and beginning of 2024!
[0] http://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-k... [1] https://news.opensuse.org/2023/12/20/systemd-fde/ [2] https://en.opensuse.org/Systemd-fde
Hi aplanas and Ludwig, I have been testing out systemd-boot and overall it seems to be working fine. The test system is UFEI with secure boot enabled but I do NOT use FDE. I followed these instructions here for switching to systemd-boot https://en.opensuse.org/Systemd-boot As part of my testing I wanted to also test switching back from systemd-boot to grub2. I also got that to work, however, there is one thing I cannot seem to figure out. When TW is initially installed using grub2 the /etc/default/grub file created during installation contains the following lines: SUSE_BTRFS_SNAPSHOT_BOOTING="true" GRUB_USE_LINUXEFI="true" GRUB_DISABLE_OS_PROBER="false" GRUB_ENABLE_CRYPTODISK="n" GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16" After installing systemd-boot and getting that working and then switching back to grub2 by reinstalling grub2 the /etc/default/grub file does NOT contain those lines. How is the initial TW install creating /etc/default/grub with those lines in it and a reinstall of grub2 does NOT contain those lines ? Obviously I worked around the issue by using the original /etc/default/grub file which I had saved but I would really like to know how the initial TW install creates the file with those lines in it. Thanks! Joe
On 28.02.2024 04:17, Joe Salmeri wrote:
When TW is initially installed using grub2 the /etc/default/grub file created during installation contains the following lines:
SUSE_BTRFS_SNAPSHOT_BOOTING="true" GRUB_USE_LINUXEFI="true" GRUB_DISABLE_OS_PROBER="false" GRUB_ENABLE_CRYPTODISK="n" GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
After installing systemd-boot and getting that working and then switching back to grub2 by reinstalling grub2 the /etc/default/grub file does NOT contain those lines.
How is the initial TW install creating /etc/default/grub with those lines in it and a reinstall of grub2 does NOT contain those lines ?
This file is managed by yast-bootlader which runs during installation.
On 2/27/24 22:55, Andrei Borzenkov wrote:
On 28.02.2024 04:17, Joe Salmeri wrote:
When TW is initially installed using grub2 the /etc/default/grub file created during installation contains the following lines:
SUSE_BTRFS_SNAPSHOT_BOOTING="true" GRUB_USE_LINUXEFI="true" GRUB_DISABLE_OS_PROBER="false" GRUB_ENABLE_CRYPTODISK="n" GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
After installing systemd-boot and getting that working and then switching back to grub2 by reinstalling grub2 the /etc/default/grub file does NOT contain those lines.
How is the initial TW install creating /etc/default/grub with those lines in it and a reinstall of grub2 does NOT contain those lines ?
This file is managed by yast-bootlader which runs during installation.
Thanks Andrei, so that explains why when I looked at the grub2 rpm contents I could not find anything that made the modifications. Is there are way ( even a manual method ) such that reinstalling grub2 ends up with the same /etc/default/grub ( and anything else that yast-bootloader process does ) as we get with a new installation? Or is this something that I just have to manually do by editing /etc/default/grub? Obviously editing is no big deal, but I don't know if there is anything else that is done by yast-bootloader during installation that I might be missing which also needs to be done when reinstalling grub2. -- Regards, Joe
participants (5)
-
Andrei Borzenkov -
aplanas -
Joe Salmeri -
Ludwig Nussel -
Luna Jernberg