Re: Disk auto-unlocking with TPM 2.0
Gary Lin wrote:
Next, reboot your system. If everything is setup correctly, the system will boot without showing the passphrase prompt.
Hello Gary Thank you for this. I am planning to test the functionality, but I am slightly wary of doing so because only my main laptop has TPM2. My back-up one, which is where I usually do tests and also keep as a hot-standby of TW, does not. I may not do this at all because I don't want to have two different configurations. So, what are the failure modes here? Assuming the set up didn't corrupt the grub configuration files, what happens if the TPM2 unlocking fails to work? Will I be simply prompted to enter my boot password like I do today? Is this also what happens if grub2 or shim change? On the technical side, how does the initrd image get checked? Grub, the kernel and the shim are stored unencrypted, but they are signed so they can be verified. The initrd image is also unencrypted and since it is created during zypper dup (half a dozen times), it can't be signed with SUSE's key. Will dracut/mkinitrd now use the TPM2 to sign/seal it? Finally, does this re-enable hibernation? I Understand from upstream developers that hibernation gets disabled because they couldn't otherwise verify that the hibernation image wasn't tampered with by the user. That is, the hibernation image contains a valid state for the current kernel, but that state is not what a securely-booted kernel wrote. If it does enable hibernation, do I understand correctly that such hibernation will still be disabled if the TPM boot fails and I have to type the password? If it's not enabled, do you have a timeline for when that will be supported? PS: would be nice to have a toggle for re-enabling hibernation even without TPM2, such my old laptop or with the current set ups. In order to attack the system as described above, one needs to know the swap password. AFAIU, the functionality exists to prevent the user from attacking the system, but that is only possible if the root filesystem and kernel are also dm-verity and thus unmodifiable by the admin. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
On Mon, Jul 31, 2023 at 09:44:56PM -0700, Thiago Macieira wrote:
Hi Thiago,
Thanks for considering testing the feature :)
Yes, in the grub2 configuration file, it falls back to the password prompt when TPM2 unsealing fails. This also applies to the boot component changes.
By default, YaST installer includes /boot in the root partition and encrypts the whole root partition. That means the kernel and initrd are stored in an encrypted partition. On the other hand, shim and grub2 are in the unencrypted EFI system partiton, so we decide the key sealing to include only the measurements of the firmware, shim, and grub2.
For the S4 status, I have to check with the kernel developer. From the perspective of linux kernel, whether the password/key is unsealed by TPM or typed by the user makes no difference. It's just an input data from somewhere else. I'm not sure if there is a S4 toggle to detect whether the swap is encrypted or not. Cheers, Gary Lin
On Monday, 31 July 2023 23:19:25 PDT Gary Lin wrote:
Good to know, thanks.
Ah, I see. I must have an old set up then from 2021, because /boot is a separate, unencrypted filesystem. That is the case in all 3 of my TW installations, including one continuously updated since 2015. This means the kernel asks for the LUKS key passwords (in the initrd), not grub. Are there steps to convert from unencrypted to encrypted /boot? It would also solve the problem of snapshotting by snapper, because /boot not being snapshot means the kernel images and the modules in /lib/modules may mismatch. Fixing those two would be beneficial by itself, regardless of whether auto- unlocking is enabled. On the other hand, auto-unlocking should not be allowed if the initrd image can't be also included in the verification process. Is this implemented?
Thank you. Looking at the patches as they're applied to kernel-default right now, there's no way to re-enable hibernation if EFI Secure Boot is enabled. When the patches were first enabled for 6.2 earlier in the year, I investigated upstream and it looked like the functionality was still in development. Corporate requires any device leaving the office premises to be hibernated or shut down while in transit. That would mean I need to turn off Secure Boot, which in turn would disable verifying that shim, grub and the kernel are intact. It might protect against theft and data loss, but not against a hack while I am away. This is why I am arguing that the lockdown protections could be counter- productive if it makes people turn off security to get hibernation back. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
On Tue, Aug 01, 2023 at 12:05:18AM -0700, Thiago Macieira wrote:
It would need at least 'cryptsetup luksFormat' on /boot partition to erase all data and then fortmatting the partition with a proper FS, the editing of /etc/fstab and /etc/crypttab, etc. Maybe YaST partitioner could make it easier, but I never try that before, to be honest.
Yes. the current default file system layout covers the snapshoted /boot to make btrfs rollback easier and more reliable.
fde-tools assumes that the whole root partition including /boot is encrypted and doesn't do this kind of check. I'll document it in the wiki.
I just chatted with our kernel developer, Joey Lee, and he provided the link to the bug: https://bugzilla.suse.com/show_bug.cgi?id=1208766#c12 Looks like it may take a long while to bring S4 back to a SB enabled system... Cheers, Gary Lin
Am Dienstag, 1. August 2023, 09:49:28 CEST schrieb Gary Lin via openSUSE Factory:
Then you end up with an encrypted /boot which is separate from /. What you want instead is to delete the old /boot and move it onto the encrypted / instead, inside the system subvolume. Something like this (obviously untested and dangerous): umount /boot/efi # if EFI system mount --move /boot /mnt rsync -avP /mnt/ /boot/ mount /boot/efi # if EFI system gawk -i inplace '$2 != "/boot"' /etc/fstab update-bootloader --reinit reboot If that worked, delete the old /boot partition.
On Tue, Aug 1, 2023 at 11:07 AM Fabian Vogt <fvogt@suse.de> wrote: ...
You may also need grub2 subvolume for /boot/grub2/x86_64-efi and corresponding mount point. Which most likely will be missing in this case. Although I am not sure whether it is actually required in case of secure boot which is using a prebuilt grub2 binary not depending on external modules.
On Tuesday, 1 August 2023 00:49:28 PDT Gary Lin wrote:
Will there be any alternative to enabling hibernation back, with SB? As I've argued, assuming the insecure initrd problem is fixed, it prevents an attack scenario where the attacker is me. I can see the value of that for a situation where a third party (corporate or the vendor) wants to forbid me from installing my own kernels and running an insecure system, but that's not my case here nor I imagine for the majority of laptop OpenSUSE users. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
On Tue, Aug 01, 2023 at 08:07:33AM -0700, Thiago Macieira wrote:
The only way I can see now is to wait for the upstream patches(*) mentioned in the bug :( Gary Lin (*) https://lore.kernel.org/lkml/20221111151451.v5.7.Ifff11e11797a1bde0297577ecb...
On Mon, Jul 31, 2023 at 09:44:56PM -0700, Thiago Macieira wrote:
Hi Thiago,
Thanks for considering testing the feature :)
Yes, in the grub2 configuration file, it falls back to the password prompt when TPM2 unsealing fails. This also applies to the boot component changes.
By default, YaST installer includes /boot in the root partition and encrypts the whole root partition. That means the kernel and initrd are stored in an encrypted partition. On the other hand, shim and grub2 are in the unencrypted EFI system partiton, so we decide the key sealing to include only the measurements of the firmware, shim, and grub2.
For the S4 status, I have to check with the kernel developer. From the perspective of linux kernel, whether the password/key is unsealed by TPM or typed by the user makes no difference. It's just an input data from somewhere else. I'm not sure if there is a S4 toggle to detect whether the swap is encrypted or not. Cheers, Gary Lin
On Monday, 31 July 2023 23:19:25 PDT Gary Lin wrote:
Good to know, thanks.
Ah, I see. I must have an old set up then from 2021, because /boot is a separate, unencrypted filesystem. That is the case in all 3 of my TW installations, including one continuously updated since 2015. This means the kernel asks for the LUKS key passwords (in the initrd), not grub. Are there steps to convert from unencrypted to encrypted /boot? It would also solve the problem of snapshotting by snapper, because /boot not being snapshot means the kernel images and the modules in /lib/modules may mismatch. Fixing those two would be beneficial by itself, regardless of whether auto- unlocking is enabled. On the other hand, auto-unlocking should not be allowed if the initrd image can't be also included in the verification process. Is this implemented?
Thank you. Looking at the patches as they're applied to kernel-default right now, there's no way to re-enable hibernation if EFI Secure Boot is enabled. When the patches were first enabled for 6.2 earlier in the year, I investigated upstream and it looked like the functionality was still in development. Corporate requires any device leaving the office premises to be hibernated or shut down while in transit. That would mean I need to turn off Secure Boot, which in turn would disable verifying that shim, grub and the kernel are intact. It might protect against theft and data loss, but not against a hack while I am away. This is why I am arguing that the lockdown protections could be counter- productive if it makes people turn off security to get hibernation back. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
On Tue, Aug 01, 2023 at 12:05:18AM -0700, Thiago Macieira wrote:
It would need at least 'cryptsetup luksFormat' on /boot partition to erase all data and then fortmatting the partition with a proper FS, the editing of /etc/fstab and /etc/crypttab, etc. Maybe YaST partitioner could make it easier, but I never try that before, to be honest.
Yes. the current default file system layout covers the snapshoted /boot to make btrfs rollback easier and more reliable.
fde-tools assumes that the whole root partition including /boot is encrypted and doesn't do this kind of check. I'll document it in the wiki.
I just chatted with our kernel developer, Joey Lee, and he provided the link to the bug: https://bugzilla.suse.com/show_bug.cgi?id=1208766#c12 Looks like it may take a long while to bring S4 back to a SB enabled system... Cheers, Gary Lin
Am Dienstag, 1. August 2023, 09:49:28 CEST schrieb Gary Lin via openSUSE Factory:
Then you end up with an encrypted /boot which is separate from /. What you want instead is to delete the old /boot and move it onto the encrypted / instead, inside the system subvolume. Something like this (obviously untested and dangerous): umount /boot/efi # if EFI system mount --move /boot /mnt rsync -avP /mnt/ /boot/ mount /boot/efi # if EFI system gawk -i inplace '$2 != "/boot"' /etc/fstab update-bootloader --reinit reboot If that worked, delete the old /boot partition.
On Tue, Aug 1, 2023 at 11:07 AM Fabian Vogt <fvogt@suse.de> wrote: ...
You may also need grub2 subvolume for /boot/grub2/x86_64-efi and corresponding mount point. Which most likely will be missing in this case. Although I am not sure whether it is actually required in case of secure boot which is using a prebuilt grub2 binary not depending on external modules.
On Tuesday, 1 August 2023 00:49:28 PDT Gary Lin wrote:
Will there be any alternative to enabling hibernation back, with SB? As I've argued, assuming the insecure initrd problem is fixed, it prevents an attack scenario where the attacker is me. I can see the value of that for a situation where a third party (corporate or the vendor) wants to forbid me from installing my own kernels and running an insecure system, but that's not my case here nor I imagine for the majority of laptop OpenSUSE users. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
participants (4)
-
Andrei Borzenkov -
Fabian Vogt -
Gary Lin -
Thiago Macieira