Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Sa, 27.05.23 08:31, Felix Rubio (fe...@kngnt.org) wrote: > Hi Lennart, > > I remember having read some time ago that UKI could pose problems with > early-boot modules provided by vendors and so. But... let's give it a try! > Then, the process should be: > > 1. Install a version of shim signed with MS keys. > 2. Generate the UKI > 3. rename the UKI image to grubx64.efi so that it gets picked up by shim > > As a side: the ESP partition is bit small. Do you think if I introduce > systemd-boot I could load the UKI being stored from /boot? In that case this > would be like > > 1. Install a version of shim signed with MS keys. > 2. Install systemd-boot as grubx64.efi so that it gets picked up by shim > 3. Generate the UKI to /boot/ > > I will give it a try... and see how it goes. systemd-boot can look into either ESP or XBOOTLDR for UKIs btw, precisely to deal with the problems around sizing ESP. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Mo, 29.05.23 11:42, Felix Rubio (fe...@kngnt.org) wrote: > Hi everybody, > > Continuing the work/learning path I started last week, I have had a > development: Still with shim loading systemd-boot, which can read the kernel > and initramfs from XBOOTLDR partition, I have introduced LUKS to encrypt the > root partition (XBOOTLDR is not encrypted). > > Originally I was planning to move from this to UKI so that I can make sure > that both kernel and initramfs are checked before booting, but today I have > considered a different course of action: Should I use the TPM to store a key > to decrypt the disk like this: > > systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+1+7+9 > > Then, by using PCR9 the initrd would be checked before allowing the boot > sequence to continue. By doing this, then, I do not have to switch to UKI > until I have learned more about it. > > Do you guys think this reasoning is flawed? So, fixing things to literal PCR values is problematic during updates, since you need to reseal with expected PCR versions befor you allow the updates to happen. With UKIs and the signed PCR logic you can instead sign PCR values and then bind disk encryption to the public key used for that signing, and include the signature matching a kernel in the UKI. That means updating becomes trivial, as every UKI comes with all data needed to unlock the disk safely. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Just to close this off, because you guys have spend time in helping me navigate through this: Finally I decided to go for FDE based on the TPM. Then, most of my concerns where addressed by using PCRs 0,1,7 and 9, so that initramfs gets also measured. This allows me to keep a separate boot partition, and to not get involved yet with UKI. Now I am trying to work out a way to smooth the case when after a kernel / modules update the TPM state changes and will not unlock automatically... but this for another day, I guess :-) Thank you very much for you help! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-27 08:31, Felix Rubio wrote: Hi Lennart, I remember having read some time ago that UKI could pose problems with early-boot modules provided by vendors and so. But... let's give it a try! Then, the process should be: 1. Install a version of shim signed with MS keys. 2. Generate the UKI 3. rename the UKI image to grubx64.efi so that it gets picked up by shim As a side: the ESP partition is bit small. Do you think if I introduce systemd-boot I could load the UKI being stored from /boot? In that case this would be like 1. Install a version of shim signed with MS keys. 2. Install systemd-boot as grubx64.efi so that it gets picked up by shim 3. Generate the UKI to /boot/ I will give it a try... and see how it goes. Regards! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi everybody, Continuing the work/learning path I started last week, I have had a development: Still with shim loading systemd-boot, which can read the kernel and initramfs from XBOOTLDR partition, I have introduced LUKS to encrypt the root partition (XBOOTLDR is not encrypted). Originally I was planning to move from this to UKI so that I can make sure that both kernel and initramfs are checked before booting, but today I have considered a different course of action: Should I use the TPM to store a key to decrypt the disk like this: systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+1+7+9 Then, by using PCR9 the initrd would be checked before allowing the boot sequence to continue. By doing this, then, I do not have to switch to UKI until I have learned more about it. Do you guys think this reasoning is flawed? Thank you, --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Lennart, I remember having read some time ago that UKI could pose problems with early-boot modules provided by vendors and so. But... let's give it a try! Then, the process should be: 1. Install a version of shim signed with MS keys. 2. Generate the UKI 3. rename the UKI image to grubx64.efi so that it gets picked up by shim As a side: the ESP partition is bit small. Do you think if I introduce systemd-boot I could load the UKI being stored from /boot? In that case this would be like 1. Install a version of shim signed with MS keys. 2. Install systemd-boot as grubx64.efi so that it gets picked up by shim 3. Generate the UKI to /boot/ I will give it a try... and see how it goes. Regards! -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-25 10:26, Lennart Poettering wrote: On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Do, 25.05.23 10:08, Andrea Pappacoda (and...@pappacoda.it) wrote: > Il giorno mer 24 mag 2023 alle 14:35:05 +02:00:00, Lennart Poettering > ha scritto: > > Note that in systemd git main there's already support for generating > > UKIs dynamically when a kernel RPM/DEB is installed (as long as the > > "kernel-install" infra is in use). It can be signed with a local key, > > that can be enrolled with MOK. > > This sounds really interesting! Could you please point to some documentation > about this feature? I'd like to try it out on my Debian system, if possible. This has not been released yet in a stable release. It has been merged into git main though. See this for the original PR: https://github.com/systemd/systemd/pull/27262 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Mi, 24.05.23 19:01, Felix Rubio (fe...@kngnt.org) wrote: > Hi Lennart, > > "Sorry, but GPG is a no-go. Not in 2023." > > Yes, I understand that. What I am trying to get is a simple way to verify > that the initramfs has not been tampered with. UKI comes with its own > challenges, using encryption tied to a measured boot looks overkill, and I > fully agree in which adding an authentication layer is not > desirable. I am not sure what "challenges" you specifically have in mind, but a UKI with an initrd in a PE envelope (i.e. the "add-on" concept I mentioned), then you should be pretty close to current behaviour, no? > Then... what alternatives are available for just performing verification of > the initramfs? I was giving a look at IMA now, so this could be sorted with > a policy... but I think this is not supported in sd-boot. IMA verifies files after the kernel is up, not before. It's not suitable for validating initrds. Anway, you should really ask yourself what cryptographic key you want to authenticate against. Local or vendor one, and where shall it be stored. That dictates your choices more than anything else. > In the case I wrap the initramfs on a PE envelope, as you suggested, when > then its signature be validated automatically? when it gets loaded? Because, > if so... this would work enough for this use case. In the "add-on" module for UKIs I mentioned the validation of both the UKI and the add-ons are done via regular UEFI SecureBoot or via shim. Both UKIs and add-ons are just PE files after all that thus can be verified that way. Because the files can be authenticated via shim you get MOK and so on. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Il giorno mer 24 mag 2023 alle 14:35:05 +02:00:00, Lennart Poettering ha scritto: Note that in systemd git main there's already support for generating UKIs dynamically when a kernel RPM/DEB is installed (as long as the "kernel-install" infra is in use). It can be signed with a local key, that can be enrolled with MOK. This sounds really interesting! Could you please point to some documentation about this feature? I'd like to try it out on my Debian system, if possible. Thanks!
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Lennart, "Sorry, but GPG is a no-go. Not in 2023." Yes, I understand that. What I am trying to get is a simple way to verify that the initramfs has not been tampered with. UKI comes with its own challenges, using encryption tied to a measured boot looks overkill, and I fully agree in which adding an authentication layer is not desirable. Then... what alternatives are available for just performing verification of the initramfs? I was giving a look at IMA now, so this could be sorted with a policy... but I think this is not supported in sd-boot. In the case I wrap the initramfs on a PE envelope, as you suggested, when then its signature be validated automatically? when it gets loaded? Because, if so... this would work enough for this use case. Thank you --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-24 18:11, Lennart Poettering wrote: On Mi, 24.05.23 16:20, Felix Rubio (fe...@kngnt.org) wrote: Hi Andrei, Lennart @Andrei: Do you think, then, that the same private key used for SecureBoot could be used for GPG signing the initramfs? That would be cool, as the whole boot signing infrastructure would still depend on a single entity. @Lennart: I was thinking in using a private key for which I'd enroll the certificate in MOK (I mean, just following the standard use case for MOK). Without having much idea about the code base of systemd-boot, I am willing to give it a try (to a GPG with private key from SB) provided you think is something the community might benefit from. What are your thoughts? Sorry, but GPG is a no-go. Not in 2023. But also I am not sure I understand what are you trying to do? Note that shim only authenticates PE binaries, hence you'd have to wrap your initrd in a PE binary anyway to validate an initrd against MOK. And we really don#t want to add another layer of authentication in sd-boot, let's leave that in uefi sb firmware + shim. i.e. we expressly don#t want to embedd a crypto stack like grub. And even if we could we don't get access to MOK iirc, shim makes that impossible for later boot components. If you wrap your initrd in a PE envelope this is pretty much exactly what UKIs are. – Also note that there's currently a PR pending that allows wrapping kernel command lines in separate PE files which can be read by a UKI, a concept we call "add-on", which would we could extend to initrds too i guess, see https://github.com/systemd/systemd/pull/27358 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Mi, 24.05.23 16:20, Felix Rubio (fe...@kngnt.org) wrote: > Hi Andrei, Lennart > > @Andrei: Do you think, then, that the same private key used for SecureBoot > could be used for GPG signing the initramfs? That would be cool, as the > whole boot signing infrastructure would still depend on a single entity. > > @Lennart: I was thinking in using a private key for which I'd enroll the > certificate in MOK (I mean, just following the standard use case for MOK). > > Without having much idea about the code base of systemd-boot, I am willing > to give it a try (to a GPG with private key from SB) provided you think is > something the community might benefit from. What are your thoughts? Sorry, but GPG is a no-go. Not in 2023. But also I am not sure I understand what are you trying to do? Note that shim only authenticates PE binaries, hence you'd have to wrap your initrd in a PE binary anyway to validate an initrd against MOK. And we really don#t want to add another layer of authentication in sd-boot, let's leave that in uefi sb firmware + shim. i.e. we expressly don#t want to embedd a crypto stack like grub. And even if we could we don't get access to MOK iirc, shim makes that impossible for later boot components. If you wrap your initrd in a PE envelope this is pretty much exactly what UKIs are. – Also note that there's currently a PR pending that allows wrapping kernel command lines in separate PE files which can be read by a UKI, a concept we call "add-on", which would we could extend to initrds too i guess, see https://github.com/systemd/systemd/pull/27358 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Andrei, Lennart @Andrei: Do you think, then, that the same private key used for SecureBoot could be used for GPG signing the initramfs? That would be cool, as the whole boot signing infrastructure would still depend on a single entity. @Lennart: I was thinking in using a private key for which I'd enroll the certificate in MOK (I mean, just following the standard use case for MOK). Without having much idea about the code base of systemd-boot, I am willing to give it a try (to a GPG with private key from SB) provided you think is something the community might benefit from. What are your thoughts? Regards, -- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-24 14:35, Lennart Poettering wrote: On Mi, 24.05.23 12:22, Felix Rubio (fe...@kngnt.org) wrote: I agree that having a measured boot, that decrypts the system is a better solution... but this is, correct me if wrong, still very green: There are some approaches supported, but none of them seems to be structural: they rely on the existence of a TPM, introduce additional dependencies on the update process (when the kernel/initramfs changes the previous measurement will not be correct anymore and needs to be updated), etc. On the other hand UKI comes with its own challenges, and also forces the admin to rebuild the UKI any time there is an update. I feel there should be some middle point in which we do not have to rely on a TPM and a fully measured system, but we can still make sure that the initramfs is trusted. The question, then, is: Is this something that could be supported in systemd-boot, or this is something that is considered to be just out of scope? As in the other mail: Which key do you intend to use for validation? Note that in systemd git main there's already support for generating UKIs dynamically when a kernel RPM/DEB is installed (as long as the "kernel-install" infra is in use). It can be signed with a local key, that can be enrolled with MOK. With that we make it reasonably easy to run a setup with a locally signed initrd – but it means that you'll get a MOK prompt during at least one boot. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Mi, 24.05.23 12:22, Felix Rubio (fe...@kngnt.org) wrote: > I agree that having a measured boot, that decrypts the system is a better > solution... but this is, correct me if wrong, still very green: There are > some approaches supported, but none of them seems to be structural: they > rely on the existence of a TPM, introduce additional dependencies on the > update process (when the kernel/initramfs changes the previous measurement > will not be correct anymore and needs to be updated), etc. On the other hand > UKI comes with its own challenges, and also forces the admin to rebuild the > UKI any time there is an update. > > I feel there should be some middle point in which we do not have to rely on > a TPM and a fully measured system, but we can still make sure that the > initramfs is trusted. The question, then, is: Is this something that could > be supported in systemd-boot, or this is something that is considered to be > just out of scope? As in the other mail: Which key do you intend to use for validation? Note that in systemd git main there's already support for generating UKIs dynamically when a kernel RPM/DEB is installed (as long as the "kernel-install" infra is in use). It can be signed with a local key, that can be enrolled with MOK. With that we make it reasonably easy to run a setup with a locally signed initrd – but it means that you'll get a MOK prompt during at least one boot. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Di, 23.05.23 20:54, Felix Rubio (fe...@kngnt.org) wrote: > Hi everybody, > > I am trying to understand something, and after looking around I have not > found any explicit answer. Maybe somebody in this list can shed some light > on the matter? I have a laptop in which I am setting up the boot process > through systemd-boot, and this works. Now, I'd like to give a try to enable > Secure Boot so that the whole boot sequence is protected against tampering. > As I am still learning about the technology, I prefer to land on the use of > shim/MOK. For what I have read, the sequence should be: > > 1. Install a version of shim signed with MS keys. > 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as > shim seems to work only with Grub as 2nd stage loader). > 3. Sign the kernel with the key for which the certificate has been enrolled > in MOK. > 4. Reboot, enroll the keys and... voila. > > So far, so good... until we hit the initramfs wall: the efi's and kernel > signatures are verified, but not that of the initramfs. I have seen that > grub2 does not do it (it relies in GPG signatures, in which seems to be a > workaround), and I have not found any place stating that systemd-boot does > it. I have seen however, some steering towards the use of UKI... but this > comes with its own problems about out-of-tree kernel modules and so. > > So, the question is: why the kernel image gets verified but not the > initramfs? Is this mandated by some standard, or is an engineering decision? What key do you want to verify it with? The OS vendor key? this is what we are building with UKI. But this means no locally build initrds, which is what distros so far were all doing. A local key? Where is that stored? In the ESP? That would be pointless, as you could swap it out. You could use a MOK key, but that means intraction at at least one boot, which generic distros don't like. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On Wed, May 24, 2023 at 1:22 PM Felix Rubio wrote: > > Hi Andrei, > > Thank you for correcting my statement about Grub2, I did not know that. > > I agree that having a measured boot, that decrypts the system is a > better solution... but this is, correct me if wrong, still very green: > There are some approaches supported, but none of them seems to be > structural: they rely on the existence of a TPM, introduce additional > dependencies on the update process (when the kernel/initramfs changes > the previous measurement will not be correct anymore and needs to be > updated), etc. On the other hand UKI comes with its own challenges, and > also forces the admin to rebuild the UKI any time there is an update. > > I feel there should be some middle point in which we do not have to rely > on a TPM and a fully measured system, but we can still make sure that > the initramfs is trusted. The question, then, is: Is this something that > could be supported in systemd-boot, or this is something that is > considered to be just out of scope? > Secure Boot defines signatures for executable PE files. To apply it to initrd one would need to either wrap it in PE (which is effectively what UKI does) or develop a new standard for attaching signature to initrd. For example, using grub2 GPG keys :) > Thank you > > --- > Felix Rubio > "Don't believe what you're told. Double check." > > On 2023-05-23 21:32, Andrei Borzenkov wrote: > > On 23.05.2023 21:54, Felix Rubio wrote: > >> Hi everybody, > >> > >> I am trying to understand something, and after looking around I have > >> not > >> found any explicit answer. Maybe somebody in this list can shed some > >> light on the matter? I have a laptop in which I am setting up the boot > >> process through systemd-boot, and this works. Now, I'd like to give a > >> try to enable Secure Boot so that the whole boot sequence is protected > >> against tampering. As I am still learning about the technology, I > >> prefer > >> to land on the use of shim/MOK. For what I have read, the sequence > >> should be: > >> > >> 1. Install a version of shim signed with MS keys. > >> 2. On that same folder copy systemd-bootx64.efi, renamed to > >> grubx64.efi > >> (as shim seems to work only with Grub as 2nd stage loader). > >> 3. Sign the kernel with the key for which the certificate has been > >> enrolled in MOK. > >> 4. Reboot, enroll the keys and... voila. > >> > >> So far, so good... until we hit the initramfs wall: the efi's and > >> kernel > >> signatures are verified, but not that of the initramfs. I have seen > >> that > >> grub2 does not do it (it relies in GPG signatures, in which seems to > >> be > >> a workaround), and I have not found any place stating that > >> systemd-boot > > > > GPG is independent alternative method of verifying files and most > > certainly not a workaround (it was implemented in grub2 long before > > Secure Boot support). > > > >> does it. I have seen however, some steering towards the use of UKI... > >> but this comes with its own problems about out-of-tree kernel modules > >> and so. > >> > >> So, the question is: why the kernel image gets verified but not the > >> initramfs? Is this mandated by some standard, or is an engineering > >> decision? > >> > > > > Kernel image has verifiable origin (it is signed by the same entity > > that provides your distribution). It is static and does not change on > > end user system which makes it possible to sign by maintainers of > > distribution by a secret key that is hopefully kept secret. > > > > initrd is volatile, it is usually generated on the same system where > > it should be verified which means the key to sign it must be kept on > > the same system as well. Which makes it more probable that secret key > > will be leaked if system is compromised. And leaked secret key allows > > installing an arbitrary malware as part of initrd. > > > > Measured boot does not have this problem. If you encrypt your root and > > only allow decrypting if initrd (and kernel and any other data used > > during boot) has known content then initrd will be implicitly verified > > and if it is changed system simply fails to boot. This does not > > require any key management or storing any persistent secret on end > > system. Downside is that it requires TPM (or some other tamper > > resistant way to store hashes) so not universally applicable. > > > >> Thank you very much! > >>
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi Andrei, Thank you for correcting my statement about Grub2, I did not know that. I agree that having a measured boot, that decrypts the system is a better solution... but this is, correct me if wrong, still very green: There are some approaches supported, but none of them seems to be structural: they rely on the existence of a TPM, introduce additional dependencies on the update process (when the kernel/initramfs changes the previous measurement will not be correct anymore and needs to be updated), etc. On the other hand UKI comes with its own challenges, and also forces the admin to rebuild the UKI any time there is an update. I feel there should be some middle point in which we do not have to rely on a TPM and a fully measured system, but we can still make sure that the initramfs is trusted. The question, then, is: Is this something that could be supported in systemd-boot, or this is something that is considered to be just out of scope? Thank you --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-23 21:32, Andrei Borzenkov wrote: On 23.05.2023 21:54, Felix Rubio wrote: Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot GPG is independent alternative method of verifying files and most certainly not a workaround (it was implemented in grub2 long before Secure Boot support). does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Kernel image has verifiable origin (it is signed by the same entity that provides your distribution). It is static and does not change on end user system which makes it possible to sign by maintainers of distribution by a secret key that is hopefully kept secret. initrd is volatile, it is usually generated on the same system where it should be verified which means the key to sign it must be kept on the same system as well. Which makes it more probable that secret key will be leaked if system is compromised. And leaked secret key allows installing an arbitrary malware as part of initrd. Measured boot does not have this problem. If you encrypt your root and only allow decrypting if initrd (and kernel and any other data used during boot) has known content then initrd will be implicitly verified and if it is changed system simply fails to boot. This does not require any key management or storing any persistent secret on end system. Downside is that it requires TPM (or some other tamper resistant way to store hashes) so not universally applicable. Thank you very much!
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On 23.05.2023 21:54, Felix Rubio wrote: Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot GPG is independent alternative method of verifying files and most certainly not a workaround (it was implemented in grub2 long before Secure Boot support). does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Kernel image has verifiable origin (it is signed by the same entity that provides your distribution). It is static and does not change on end user system which makes it possible to sign by maintainers of distribution by a secret key that is hopefully kept secret. initrd is volatile, it is usually generated on the same system where it should be verified which means the key to sign it must be kept on the same system as well. Which makes it more probable that secret key will be leaked if system is compromised. And leaked secret key allows installing an arbitrary malware as part of initrd. Measured boot does not have this problem. If you encrypt your root and only allow decrypting if initrd (and kernel and any other data used during boot) has known content then initrd will be implicitly verified and if it is changed system simply fails to boot. This does not require any key management or storing any persistent secret on end system. Downside is that it requires TPM (or some other tamper resistant way to store hashes) so not universally applicable. Thank you very much!
[systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Thank you very much! -- Felix Rubio "Don't believe what you're told. Double check."
