Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure. To still support secure boot, the kernel image would have to be signed be key stored on disk on every update. If the disk is encrypted, the private key can still be protected from attackers. On installation, or update for existing installs, a public/private keypair would be generated, and trusted by the shim.
This has a few problems, if the root user is hacked, then the kernel can be tampered with. But this is not a very big problem because if the root user is hacked, then for example systemd can be changed, secure boot will not protect you. It will also mean that if the user want to modify the kernel command line or initrd, they have to regenerate the entire kernel image. This can also break some users install, if they use a non-default boot process, or have a buggy uefi implementation. For non-uefi architectures, this change could be ignored.
On 19/06/2022 22:54, Sharpened Blade via devel wrote:
This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
What about proprietary NVIDIA drivers?
Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed.
On 27/06/2022 21:19, Sharpened Blade via devel wrote:
Akmods can automatically sign kernel modules, its just a few commands and then every version will be signed.
Yes, but anyone can read your private keys to sign anything. Someone needs to implement support for hardware tokens, or at least TPM 2.0.
It would be stored with permissions for only root to read it, and you disk should be encrypted, or none of this matters.
Sharpened Blade via devel devel@lists.fedoraproject.org wrote:
It would be stored with permissions for only root to read it, and you disk should be encrypted, or none of this matters.
It doesn't matter if your disk is encrypted. Whilst your computer is online, the contents are accessible. If your kernel memory is accessible through /dev/mem or /dev/kmem, there's a chance that your keys can just be read directly.
One of the things secure boot can do is lock down *read* access to your raw memory/kernel virtual memory to make it harder for someone to steal your secrets. It's not a secure as using a TPM ought to be, though.
And if you want to keep your key safe, you should really keep it in a removable hardware device. Leaving it on your hard drive, even with perms such that only root can read it isn't necessarily safe enough, sadly.
David
A key on an encrypted disk can still prevent evil maid attacks, though an attacker with local access can still compromise the system. In the current system, an attacker with permissions required to read kernel memory can just ask the shim to boot their modified kernel.
V Tue, Jun 28, 2022 at 08:27:16PM +0100, David Howells napsal(a):
Sharpened Blade via devel devel@lists.fedoraproject.org wrote:
It would be stored with permissions for only root to read it, and you disk should be encrypted, or none of this matters.
It doesn't matter if your disk is encrypted. Whilst your computer is online, the contents are accessible. If your kernel memory is accessible through /dev/mem or /dev/kmem, there's a chance that your keys can just be read directly.
If one can read /dev/mem, he can edit any executable or PAM configuration, in memory or on a disk, to assure a permanent acccess or to steal any data existing right now.
There is a little benefit of stealing private keys if you have all data available right now. The only benefit is future off-line attacks by being able to sign data of your choice. E.g. if you are Microsoft which signs shim so that Fedora can actually boot on Secure Boot-enabled devices.
One of the things secure boot can do is lock down *read* access to your raw memory/kernel virtual memory to make it harder for someone to steal your secrets. It's not a secure as using a TPM ought to be, though.
You don't need need a secure boot for that. Simply compile your kernel with CONFIG_STRICT_DEVMEM=y or CONFIG_DEVMEM=n or any similar hardening option.
-- Petr
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
Regards.
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
-- 真実はいつも一つ！/ Always, there's only one truth!
* Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
Thanks, Florian
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is.
The latest akmods version can automatically sign kernel modules, it could even be enabled by default.
On 6/27/22 13:34, Chris Murphy wrote:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is.
The alternative is to accept that UEFI Secure Boot only provides meaningful security if the default signing keys (in particular, Microsoft’s) are not installed. On Windows, administrator to kernel is not considered a security boundary, so there is no point pretending it is one on Linux if the attacker can just boot Windows. If you are interested in *actual* pre-boot security, I suggest Heads (https://osresearch.net) or at least enrolling your own certificates (which should be sealed to the TPM such that the private keys are only available after successful boot of a signed OS). The initramfs also needs to be signed, and the signature needs to be checked before it is run.
* Chris Murphy:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is.
Do we revoke signatures on Fedora kernels with ring 0 escalations? I don't think so. Other distributions share the same trust root and do not revoke kernel signatures, either. Doesn't this mean there is an existing bypass already, by booting through a vulnerable kernel, exploiting it, and then chain-loading another kernel with secure boot effectively disabled (but perhaps lying to userspace about the status)?
Thanks, Florian
On 6/28/22 07:21, Florian Weimer wrote:
- Chris Murphy:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer fweimer@redhat.com wrote:
- Neal Gompa:
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Right. It's not even clear to me why we enforce kernel module signatures in Secure Boot mode, and disable a few other kernel features.
If users can load arbitrary unsigned kernel modules or hibernation images, it silently circumvents UEFI Secure Boot. I agree this is a frustrating paradigm for users who want certain features like using 3rd party modules with a Fedora kernel, or using locked down kernel features, but I'm not sure what the alternative is.
Do we revoke signatures on Fedora kernels with ring 0 escalations? I don't think so. Other distributions share the same trust root and do not revoke kernel signatures, either. Doesn't this mean there is an existing bypass already, by booting through a vulnerable kernel, exploiting it, and then chain-loading another kernel with secure boot effectively disabled (but perhaps lying to userspace about the status)?
Yes, it does. That is another reason that secure boot is basically security theater if one is using the default trust roots.
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Many of the same issues & concepts from Secure Boot are involved in confidential virtualization technology. This provides mechanism to boot virtual machines on public cloud hosts, with strong protection against a malicious host OS user snooping on what's going on in your VM. You establish a trust relationship with the CPU hardware/firmware, and once verified you can be confident the VM is booted with the guest firmware, bootloader, kernel, initrd, cmdline that you deployed. This will close one of the biggest security gaps between public cloud and running on hardware you own & control yourself, so will be relevant to anyone who uses cloud. Being able to improve kernel/initrd/cmdline handling for SecureBoot will be beneficial for confidential computing, and vica-verca.
With regards, Daniel
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Many of the same issues & concepts from Secure Boot are involved in confidential virtualization technology. This provides mechanism to boot virtual machines on public cloud hosts, with strong protection against a malicious host OS user snooping on what's going on in your VM. You establish a trust relationship with the CPU hardware/firmware, and once verified you can be confident the VM is booted with the guest firmware, bootloader, kernel, initrd, cmdline that you deployed. This will close one of the biggest security gaps between public cloud and running on hardware you own & control yourself, so will be relevant to anyone who uses cloud. Being able to improve kernel/initrd/cmdline handling for SecureBoot will be beneficial for confidential computing, and vica-verca.
That's flawed. As long as you don't control the hypervisor stack, you can't establish a trust relationship. Confidental computing is fundamentally broken in the public cloud because the public cloud provider can do whatever it wants to the hypervisor stack. If it was a private cloud infrastructure you ran, that's a different story.
On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Many of the same issues & concepts from Secure Boot are involved in confidential virtualization technology. This provides mechanism to boot virtual machines on public cloud hosts, with strong protection against a malicious host OS user snooping on what's going on in your VM. You establish a trust relationship with the CPU hardware/firmware, and once verified you can be confident the VM is booted with the guest firmware, bootloader, kernel, initrd, cmdline that you deployed. This will close one of the biggest security gaps between public cloud and running on hardware you own & control yourself, so will be relevant to anyone who uses cloud. Being able to improve kernel/initrd/cmdline handling for SecureBoot will be beneficial for confidential computing, and vica-verca.
That's flawed. As long as you don't control the hypervisor stack, you can't establish a trust relationship. Confidental computing is fundamentally broken in the public cloud because the public cloud provider can do whatever it wants to the hypervisor stack. If it was a private cloud infrastructure you ran, that's a different story.
No, that is not the case, what you describe is the traditional virtualizaton scenario, where hypervisor "root" is all-powerful over everything, with no way to limit that that can be trusted by guest owners. Confidential computing (for example AMD's SEV-SNP or Intel TDX) is about using new CPU hardware & firmware features to prevent the cloud provider from doing whatever they like. It further provides a way for the guest owner to cryptographically validate this is the case at boot time, such that the VM owner can ensure it will not boot if the host admin tampered with the requested execution environment. There is a decent overview of threats that SEV-SNP aims to protect against here:
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation...
With regards, Daniel
On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
> Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Many of the same issues & concepts from Secure Boot are involved in confidential virtualization technology. This provides mechanism to boot virtual machines on public cloud hosts, with strong protection against a malicious host OS user snooping on what's going on in your VM. You establish a trust relationship with the CPU hardware/firmware, and once verified you can be confident the VM is booted with the guest firmware, bootloader, kernel, initrd, cmdline that you deployed. This will close one of the biggest security gaps between public cloud and running on hardware you own & control yourself, so will be relevant to anyone who uses cloud. Being able to improve kernel/initrd/cmdline handling for SecureBoot will be beneficial for confidential computing, and vica-verca.
That's flawed. As long as you don't control the hypervisor stack, you can't establish a trust relationship. Confidental computing is fundamentally broken in the public cloud because the public cloud provider can do whatever it wants to the hypervisor stack. If it was a private cloud infrastructure you ran, that's a different story.
No, that is not the case, what you describe is the traditional virtualizaton scenario, where hypervisor "root" is all-powerful over everything, with no way to limit that that can be trusted by guest owners. Confidential computing (for example AMD's SEV-SNP or Intel TDX) is about using new CPU hardware & firmware features to prevent the cloud provider from doing whatever they like. It further provides a way for the guest owner to cryptographically validate this is the case at boot time, such that the VM owner can ensure it will not boot if the host admin tampered with the requested execution environment. There is a decent overview of threats that SEV-SNP aims to protect against here:
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation...
Why are you assuming that can't be faked? We can fake secure enclaves for virtualization, there's no reason that can't be faked too.
On Mon, Jun 27, 2022 at 08:12:08AM -0400, Neal Gompa wrote:
On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Mon, Jun 27, 2022 at 07:46:29AM -0400, Neal Gompa wrote:
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Sat, Jun 25, 2022 at 08:43:18PM -0400, Neal Gompa wrote:
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote: > On 6/19/22 22:54, Sharpened Blade via devel wrote: > >> Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. > > How big is the demand for this kind of lockdown? > As a since-last-century Linux user, I'm choosing Fedora > exactly to NOT have all this signing/trusted boot > complications on my systems and I do not see a reason > to turn Fedora into Android (or, worse, iOS). It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Many of the same issues & concepts from Secure Boot are involved in confidential virtualization technology. This provides mechanism to boot virtual machines on public cloud hosts, with strong protection against a malicious host OS user snooping on what's going on in your VM. You establish a trust relationship with the CPU hardware/firmware, and once verified you can be confident the VM is booted with the guest firmware, bootloader, kernel, initrd, cmdline that you deployed. This will close one of the biggest security gaps between public cloud and running on hardware you own & control yourself, so will be relevant to anyone who uses cloud. Being able to improve kernel/initrd/cmdline handling for SecureBoot will be beneficial for confidential computing, and vica-verca.
That's flawed. As long as you don't control the hypervisor stack, you can't establish a trust relationship. Confidental computing is fundamentally broken in the public cloud because the public cloud provider can do whatever it wants to the hypervisor stack. If it was a private cloud infrastructure you ran, that's a different story.
No, that is not the case, what you describe is the traditional virtualizaton scenario, where hypervisor "root" is all-powerful over everything, with no way to limit that that can be trusted by guest owners. Confidential computing (for example AMD's SEV-SNP or Intel TDX) is about using new CPU hardware & firmware features to prevent the cloud provider from doing whatever they like. It further provides a way for the guest owner to cryptographically validate this is the case at boot time, such that the VM owner can ensure it will not boot if the host admin tampered with the requested execution environment. There is a decent overview of threats that SEV-SNP aims to protect against here:
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation...
Why are you assuming that can't be faked? We can fake secure enclaves for virtualization, there's no reason that can't be faked too.
Generating the expected cryptographic measurements requires access to the right keys for signing data to establish the root of trust back to the CPU vendor. There will always be attack vectors against the firmware since no software is ever bug free. The designs take account of that by including the host firmware when validating the VM state, so the guest owner can reject known flawed older firmware versions. This really is a massive step forwards in virtualization technology and not an easy thing to defeat.
With regards, Daniel
If the system owner wanted to, they could use their own firmware/ comprimise firmware, then fake the firmware version to something new, the vm could not even be interacting with the cpu at all. Also, if the keys are in the cpu, then the keys can be extracted.
Also, whats stops the owner of the machine to run the vm in a normal hypervisor, then modify it so any attempts to check if it is "trusted" will always look real.
On 7/7/22 14:09, Sharpened Blade via devel wrote:
Also, whats stops the owner of the machine to run the vm in a normal hypervisor, then modify it so any attempts to check if it is "trusted" will always look real.
They cannot fake the attestation without somehow extracting the needed secret keys from the CPU.
Secure boot itself, when used right, actually helps your privacy. Microsoft doesn't require oems to allow the keys to be changed, so it sometimes prevents your freedom, but when implemented right, it can stop evil maid attacks. Also, even when you cant remove Microsoft keys, you can still use the shim.
On 27/06/2022 21:18, Sharpened Blade via devel wrote:
Also, even when you cant remove Microsoft keys, you can still use the shim.
If you can't remove Microsoft keys, you're nullifying the whole purpose of secure boot, because anyone can use a signed shim to boot whatever they want.
Also, if you remove Microsoft keys, you will need to sign the video and network card firmware with your own CA in order to work in SB mode.
On Tue, Jun 28, 2022 at 08:42:43AM +0200, Vitaly Zaitsev via devel wrote:
On 27/06/2022 21:18, Sharpened Blade via devel wrote:
Also, even when you cant remove Microsoft keys, you can still use the shim.
If you can't remove Microsoft keys, you're nullifying the whole purpose of secure boot, because anyone can use a signed shim to boot whatever they want.
That's thinking about the problem from the wrong point of view. SecureBoot doesn't prevent an attacker from booting an OS that's different from what you installed, even without shim they could swap to a different Windows install. What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key.
IOW, the ability to boot another OS is degraded to merely a denial of service, not a data compromise, because the other OS will be prevented from accessing the encrypted disk.
The ability to install your own keys, removing Microsoft keys, adds an additional layer that does let you lock down the machine further, but even without that it is still a useful technology [1].
With regards, Daniel
[1] at least it could be except for the huge problem of not securing the initrd that we have. That's not a secure boot problem though, that's a Linux vendor problem
On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé berrange@redhat.com wrote:
That's thinking about the problem from the wrong point of view. SecureBoot doesn't prevent an attacker from booting an OS that's different from what you installed, even without shim they could swap to a different Windows install. What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key.
I think you mistaken SecureBoot with a TPM measurement.
SecureBoot is indeed only about executing or not executing a code which is signed by a trusted key. Naturally if there are multiple trusted keys or a whole tree of signed firmwares, loaders, and operating systems, then from SecureBoot point of view, they are equivalent.
On the other hand, attesting that a system booted into the same state as yesterday is a different problem and can be achieved without any signatures. E.g. with TPM-measuring each executed piece of code and configuration data.
I can see where the misunderstanding comes from: The traditional TPM scenario requires the a user to establish the trust with TPM by seeding it with a new initialization vector. That's not practical in cloud computing where the user has no access to the hardware. Therefore CPU vendors came with a complicates structure of keys, derived keys. encrypted memory, enclaves inaccessible to a hypervizor etc. I don't know much about this. However, I believe that this security feature you are familiar to from the world of virtualization is not called SecureBoot.
-- Petr
On Tue, Jun 28, 2022 at 01:12:25PM +0200, Petr Pisar wrote:
On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé berrange@redhat.com wrote:
That's thinking about the problem from the wrong point of view. SecureBoot doesn't prevent an attacker from booting an OS that's different from what you installed, even without shim they could swap to a different Windows install. What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key.
I think you mistaken SecureBoot with a TPM measurement.
SecureBoot is indeed only about executing or not executing a code which is signed by a trusted key. Naturally if there are multiple trusted keys or a whole tree of signed firmwares, loaders, and operating systems, then from SecureBoot point of view, they are equivalent.
Well actually I was really referring to the combination of the two. SecureBoot makes the use of TPM more practical / straightforward by avoiding the need to tie the policy to measurements that change on every software update, instead you can tie to a measurement associated with successful secure boot.
With regards, Daniel
On 28/06/2022 09:26, Daniel P. Berrangé wrote:
What SecureBoot does is to provide a mechanism to assert that what has booted matches the original install, and securely tie that condition to the release of secrets for example to LUKS key.
No, it doesn't. It just blocks the ability to load unsigned code.
TPM 2.0 provides a boot chain verification mechanism.
Demi Marie Obenour demiobenour@gmail.com wrote:
On 6/25/22 07:56, Roberto Ragusa wrote:
On 6/19/22 22:54, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi.
How big is the demand for this kind of lockdown? As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
tl;dr: that's not what Secure Boot is; packed kernel+initrd images may be in the cards
As one of the people responsible for getting Fedora's shim signed and therefore making Secure Boot work, I feel it's necessary to clarify that we don't agree with any of the misinformation in this thread:
Secure Boot is not lockout. Secure Boot is not designed or even intended to keep you out of your own machine. The entire trust model assumes that if you have physical access, it's your machine: you can manipulate keys, and even turn Secure Booting off. If you don't own the machine... well, then you're an attacker, it's designed to keep you out, and as I'm not a blackhat, you'll get no help from me :)
How you configure your own hardware, should you choose to do so, is your own business and I won't tell you how to do that. But as it adds a tangible security benefit, and even if you're doing custom module/kernel/etc. builds, it's really not very difficult to add your own key and sign.
Secure Boot can be thought of as primarily a way to avoid attacker persistence on the system. Supposing someone otherwise roots the machine, by restricting boot targets to known good (as determined by machine owner or distro vendor), we make it much harder to (for example) deploy a bootkit, or load a malicious kmod. This isn't perfect (see the original post), but it's clearly better than not having it, and problems like "the initrd isn't signed" are eminently solvable.
While I will not be responding to all the dangerously incorrect things that have or can be said, here's a sample reply:
Neal Gompa ngompa13@gmail.com writes:
I only care about secure boot enough to bootstrap a Free platform.
False dichotomy. Secure Boot isn't nonfree, nor is the Fedora ecosystem somehow decoupled from it.
Secure Boot is generally not designed as a tool to provide security
Wildly, dangerously incorrect. (And it's not a tool - many components work together to enable it, including the kernel.)
unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
If you're doing custom builds, you're of course encouraged to use your own certs. How you configure your own machine is, again, your business.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
Groundless speculation, and not correct.
I treat Secure Boot purely as a compatibility interface. We need to do just enough to get through the secure boot environment.
Again, this misunderstands the security boundary.
Be well, --Robbie
On Sa, 25.06.22 20:43, Neal Gompa (ngompa13@gmail.com) wrote:
It’s necessary for secure boot to actually be meaningful in practice. I expect that people who care about secure boot will want this.
I don't. I only care about secure boot enough to bootstrap a Free platform. Secure Boot is generally not designed as a tool to provide security unless you rip out all the certs and use your own exclusively. At that point, you can do whatever you want.
This is FUD. Of course SecureBoot can improve security, if you make proper use of it, as it provides some level of offline security, i.e. that you can leave your laptop unsupervised for a minute and make it for attackers a lot harder to backdoor the boot process.
So far Linux distros didn't use it for that though — what was actually implemented was the bare minimum to make systems behave as before, not taking benefit of any of the real security benefits it offers.
And yes, if all you want is the status quo ante then SecureBoot is just a PITA. But maybe in IT security landscape of 2022 we shouldn't build systems anymore the way we built them in 1990, but make things harder to backdoor. And SecureBoot helps you with that — if one actually makes proper use of it.
Or in other words: the fact that initrds are not signed on Linux distros defeats the whole point of SecureBoot, but unsigned initrds is not an inherent idea of SecureBoot, but just a misfeature of Linux distros, and is what we should actually fix.
Most PCs are poorly designed to handle doing this procedure, and it's too easy to accidentally break the computer entirely by doing so. It's just not worth it.
What you are writing above is about as smart as saying that signed RPM packages are bad because they make it a bit harder to enroll your own RPM signing key to install your own signed packages...
Signing and authenticating the code is a good thing to protect systems – it's a good thing if we can do so for the boot code too as we boot.
Lennart
-- Lennart Poettering, Berlin
On Mon, Jul 4 2022 at 09:55:20 AM +0200, Lennart Poettering mzerqung@0pointer.de wrote:
Signing and authenticating the code is a good thing to protect systems – it's a good thing if we can do so for the boot code too as we boot.
Tangent:
After installing or upgrading your Fedora or RHEL system, you have to accept a "do you trust this official Fedora project key" prompt or you cannot install packages from the official repos. So all our users have been trained to ignore warnings about untrusted packages because it's mandatory to do so. If few users think twice about accepting a key as long as it purports to be from "Fedora" or "Red Hat"... well, the whole system is subverted. This needs a rethink.
Michael
Michael Catanzaro wrote on Mon, Jul 04, 2022 at 05:48:28PM -0500:
After installing or upgrading your Fedora or RHEL system, you have to accept a "do you trust this official Fedora project key" prompt or you cannot install packages from the official repos. So all our users have been trained to ignore warnings about untrusted packages because it's mandatory to do so. If few users think twice about accepting a key as long as it purports to be from "Fedora" or "Red Hat"... well, the whole system is subverted. This needs a rethink.
The keys come from the installed key packages and have already been written to /etc when that prompts happen -- users can trust these keys because they trusted the package that wrote them in the first place.
That being said, you could just as well look at it the other way and say that if something malcious can write keys there they could also accept the prompt for you so you wouldn't see it -- hence the prompt can be said to be useless one way or the other...
-- Dominique Martinet | Asmadeus
How big is the demand for this kind of lockdown?
It can help users security, but most users have no idea what this is. Software should be secure by itself, without users needing extra effort.
As a since-last-century Linux user, I'm choosing Fedora exactly to NOT have all this signing/trusted boot complications on my systems and I do not see a reason to turn Fedora into Android (or, worse, iOS).
This will not turn fedora even remotely similar to iOS or Android. You still completely control userspace, and can modify the kernel if you want, you just need to run the command to resign the kernel. You can also easily disable, and have no impact to the rest of the system, other than reduced security.
Sharpened Blade via devel devel@lists.fedoraproject.org wrote:
[...] Software should be secure by itself, [...]
That's impossible to achieve. Without hardware support, you cannot make your software secure.
Further, human beings are involved in the writing of the software - and the larger the codebase and the more people involved, the more bugs there will be.
Add to that the authors of Linux have spent ages providing all sorts of interesting ways for one process to affect another, from strace to /dev/mem to ebpf.
David
Also, can it be fixed so adding the --uefi flag to dracut works with the default generation scripots
On Sun, Jun 19, 2022 at 08:54:51PM -0000, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure.
I'd rather have fedora ship a unified + signed kernel image with a generic (aka 'dracut --no-hostonly') initrd instead of generating one on the local system.
That'll avoid all the hassle of local signing, key management and the private key being an attractive target for attackers.
take care, Gerd
This is a good idea, but some users might want to modify or need to modify the command line to boot, if it was signed using fedoras key, then you cant do that. Also some users dont like keeping their trust in fedora and would like to modify their kernel freely. Also, though the private key is something attackers want, if they can read or write the private key, then they can just as easily modify systemd, and get root, or install ssh with their own keys, at that point secure boot will not help you.
On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann kraxel@redhat.com wrote:
On Sun, Jun 19, 2022 at 08:54:51PM -0000, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure.
I'd rather have fedora ship a unified + signed kernel image with a generic (aka 'dracut --no-hostonly') initrd instead of generating one on the local system.
I think the issue with this is the initrd side blows out a lot, you include all the firmware for all the modules in the system and then you have 3 of them in /boot.
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
Dave.
On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote:
On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann kraxel@redhat.com wrote:
On Sun, Jun 19, 2022 at 08:54:51PM -0000, Sharpened Blade via devel wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure.
I'd rather have fedora ship a unified + signed kernel image with a generic (aka 'dracut --no-hostonly') initrd instead of generating one on the local system.
I think the issue with this is the initrd side blows out a lot, you include all the firmware for all the modules in the system and then you have 3 of them in /boot.
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
take care, Gerd
On Fri, Jul 01, 2022 at 08:30:21AM +0200, Gerd Hoffmann wrote:
On Fri, Jul 01, 2022 at 06:39:41AM +1000, David Airlie wrote:
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
That doesn't help much though if we want have a unified kernel image (aka single efi binary with kernel + initrd) to get the initrd signed that way.
Hmm.
Are there any existing approaches to sign initrds? grub seems to support detached gpg signatures. Doesn't look that attractive given that the whole secure boot process uses x509 instead so using gpg would require maintaining yet another key ...
take care, Gerd
The entire purpose of a unified kernel image is to have the initrd bundled, so it can be signed. systemd-boot also supports s multiple initrds. If there was a way to sign the initrd and command line locally, and sign have fedora sign the kernel, then there shouldn't have to be a huge initrd.
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel@redhat.com) wrote:
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack).
In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it.
(the extension images would be signed dm-verity squashfs, to ensure everything is authenticated)
Lennart
-- Lennart Poettering, Berlin
On 7/4/22 04:13, Lennart Poettering wrote:
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel@redhat.com) wrote:
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack).
In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it.
(the extension images would be signed dm-verity squashfs, to ensure everything is authenticated)
Lennart
Would the extension images also be measured into the TPM?
On Mo, 04.07.22 04:19, Demi Marie Obenour (demiobenour@gmail.com) wrote:
On 7/4/22 04:13, Lennart Poettering wrote:
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel@redhat.com) wrote:
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack).
In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it.
(the extension images would be signed dm-verity squashfs, to ensure everything is authenticated)
Would the extension images also be measured into the TPM?
Yes, precisely. Sorted alphabetically, and then measured. (And in fact, picked up by IMA too, because dm-verity is nowadays picked up by it, iirc).
Lennart
-- Lennart Poettering, Berlin
On Mon, Jul 04, 2022 at 10:13:23AM +0200, Lennart Poettering wrote:
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel@redhat.com) wrote:
I do wonder if it's possible to use multiple initrds, and maybe have the firmware in a separate initrd shared between all installed kernels if we go down this route.
grub supports multiple initrds just fine. According to https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault grub supports multiple initrd files also with bls. That seems to be a derivation from the original boot loader spec though, so not sure this works with systemd-boot too.
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack).
In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it.
That sounds good. Given their pretty homogeneous hardware I would hope that 90% figure ought to be able to reach near 100% for virtual machines on the common hypervisors/clouds (KVM, Hyper-V, VMWare, AWS)
With regards, Daniel
On Mo, 04.07.22 09:30, Daniel P. Berrangé (berrange@redhat.com) wrote:
When going for multiple initrds the best approach is probably to simply split out the kernel modules into a version-specific initrd and store everything else in another, shared initrd.
In the approach Zbginiew and I are working on we intend to build a basic initrd into the kernel itself (i.e. in a unified kernel logic) and then optionally load additional initrd images that can be placed next to the kernel image and are picked up by the EFI stub (i.e. by the EFI code that runs as part of the kernel when it runs in EFI mode still, before we transition to Linux mode, i.e. where all the EFI file systems are still accessible), and are passed to kernel, measured and then very early on overlayed on top of the basic initrd image (i.e. in an immutable overlayfs stack).
In such an approach the basic initrd would be able to just boot 90% of the systems, and for the other 10% we'd just add a couple of extension images next to the kernel image, and that's it.
That sounds good. Given their pretty homogeneous hardware I would hope that 90% figure ought to be able to reach near 100% for virtual machines on the common hypervisors/clouds (KVM, Hyper-V, VMWare, AWS)
Yes, that would be the benchmark: the most common systems should be bootable with a single unified kernel images, and that of course includes all popular virtualizers.
Lennart
-- Lennart Poettering, Berlin
On So, 19.06.22 20:54, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Use unified kernel images by default for new releases. This can allow for the local installation to sign the kernel and the initrd, so the boot chain can be verified until after the uefi. Currently, the initrd can be modified by attackers, so even if the / partition is encrypted, the systems data can be read on the next boot. If the kernel image, which includes the command line, and the initrd, is signed then it is harder to comprimise the system. The system can still be comprimised if the uefi is modified.
If this was used, then the kernel could no longer be signed in the package by the fedora infrastructure. To still support secure boot, the kernel image would have to be signed be key stored on disk on every update. If the disk is encrypted, the private key can still be protected from attackers. On installation, or update for existing installs, a public/private keypair would be generated, and trusted by the shim.
This has a few problems, if the root user is hacked, then the kernel can be tampered with. But this is not a very big problem because if the root user is hacked, then for example systemd can be changed, secure boot will not protect you. It will also mean that if the user want to modify the kernel command line or initrd, they have to regenerate the entire kernel image. This can also break some users install, if they use a non-default boot process, or have a buggy uefi implementation. For non-uefi architectures, this change could be ignored.
I do think it would make a lot of sense for Fedora to adopt unified kernels. However I think the initrd should be built on fedora infra and signed with fedora keys by default.
We have been working on building tools and filling gaps to make that workable reasonably in systemd upstream, and with a focus on Fedora. The difficulty is in both being able to prebuild everything but also keeping things somewhat modular and parameterizable. Because right now those are the primary reasons initrds are built on the installed host instead of Fedora: they contain local configuration and drivers. If we prebuild everything we must have model to replace these parts, without compromising security, and that's not rivial.
Zbigniew and I intend to present our ideas and tools about that at Linux Plumbers this year.
Lennart
-- Lennart Poettering, Berlin
Hi,
We have been working on building tools and filling gaps to make that workable reasonably in systemd upstream, and with a focus on Fedora. The difficulty is in both being able to prebuild everything but also keeping things somewhat modular and parameterizable. Because right now those are the primary reasons initrds are built on the installed host instead of Fedora: they contain local configuration and drivers. If we prebuild everything we must have model to replace these parts, without compromising security, and that's not rivial.
Is all this this discussed somewhere in public? systemd-devel list maybe?
For virtual machines we need some way to make sure they actually run the software we want them run, and it seems the options we have are:
(1) finally plug that initrd hole, or (2) use encrypted /boot
... where (2) feels more like a workaround for the unsigned initrd problem and it also opens another can of worms like requiring luks support in the boot loader.
I guess you already have a list of the "local configuration" bits which must be tackled? Obvious #1 is finding the root filesystem. Should be solvable with discoverable partitions. A few days back I've found a 7 (!) year old bug[1] of yours truly asking to support that in anaconda, still in NEW state :(
take care, Gerd
On Mo, 04.07.22 11:32, Gerd Hoffmann (kraxel@redhat.com) wrote:
Hi,
We have been working on building tools and filling gaps to make that workable reasonably in systemd upstream, and with a focus on Fedora. The difficulty is in both being able to prebuild everything but also keeping things somewhat modular and parameterizable. Because right now those are the primary reasons initrds are built on the installed host instead of Fedora: they contain local configuration and drivers. If we prebuild everything we must have model to replace these parts, without compromising security, and that's not rivial.
Is all this this discussed somewhere in public?
We'll have a session about that at Linux Plumbers Conference... There was a talk about it at devconf.cz:
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
systemd-devel list maybe?
That'd probably be the best place, yeah.
For virtual machines we need some way to make sure they actually run the software we want them run, and it seems the options we have are:
(1) finally plug that initrd hole, or (2) use encrypted /boot
... where (2) feels more like a workaround for the unsigned initrd problem and it also opens another can of worms like requiring luks support in the boot loader.
I find 2 very wrong, as it doesn't solve the actual issue (provides confidentiality, not actually authenticity). Moreover, as important as authentication is getting sane TPM measurements out of the whole thing, so that further policies can mapped to all this.
I guess you already have a list of the "local configuration" bits which must be tackled? Obvious #1 is finding the root filesystem. Should be solvable with discoverable partitions. A few days back I've found a 7 (!) year old bug[1] of yours truly asking to support that in anaconda, still in NEW state :(
In a fully trusted environment I'd expect that the immutable root fs is pinned in the kernel image via the root hash.
In a semi-trusted environment we should use GPT meta info to find the rootfs. This can either be the discovery partition sspec stuff (which I'd recommend), or if people insist a simple root=PARTLABEL=fedora or so on the kernel cmdline.
An alternative is to use the systemd credential logic for this (this stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and signing small blobs of info (so called "credentials") with the local TPM. They can then safely be stored on an untrusted medium (such as a ESP/boot partition), and are verified/decrypted on access. The "systemd-stub" EFI stub can automatically pick up such encrypted credentials from the ESP too, similar to the extension initrd images mentioned earlier in this thread.
The credentials logic can also be used to for example pass a root pw for the initrd in a safe way.
My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother.
Lennart
-- Lennart Poettering, Berlin
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
I don't think mkosi is a hard requirement for unified kernel images though. Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no?
An alternative is to use the systemd credential logic for this (this stuff: https://systemd.io/CREDENTIALS/). It allows encrypting and signing small blobs of info (so called "credentials") with the local TPM. They can then safely be stored on an untrusted medium (such as a ESP/boot partition), and are verified/decrypted on access. The "systemd-stub" EFI stub can automatically pick up such encrypted credentials from the ESP too, similar to the extension initrd images mentioned earlier in this thread.
("man systemd-stub" has details on the efi stub btw).
The credentials logic can also be used to for example pass a root pw for the initrd in a safe way.
Does systemd-cryptenroll use this?
When getting the credentials for the encrypted root filesystem (or something else) from somewhere else, i.e. some attestation server such as https://keylime.dev/, how could that be integrated with systemd-creds best? Simply have the agent write to /run/credentials?
My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother.
Yep.
Is there some fallback mechanism btw? Most cloud images have just four partitions: bios-boot, efi esp, boot and root. And the root filesystem is simply the largest partition ...
take care, Gerd
I think using credentials for the rootfs is not very useful, the user already enters the LUKS password on boot. Also, if the encryption keys are not stored locally, then they have no use, an attacker can just get them from the external storage. Many users also would not like needing an attestation service to boot either. If the encryption keys need to only be revealed on a trusted boot, then it should be stored in the tpm.
On Mo, 04.07.22 19:27, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
I think using credentials for the rootfs is not very useful, the user already enters the LUKS password on boot.
I can't parse this.
the systemd credentials stuff are not just for passing secrets or so. They can be used for any kind of config option. And they are not just encrypted but also authenticated. That means we can use them to pass root device info (i.e. a string like /dev/disk/by-uuid/…) in. For that the encryption doesn't matter, but the authentication does, as we can use the info safely after authentication, since we know it was encoded by someone who had the permission to do so.
Lennart
-- Lennart Poettering, Berlin
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
supermin has solved this problem for over a decade.
Rich.
On Mon, Jul 04, 2022 at 10:25:05PM +0100, Richard W.M. Jones wrote:
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
supermin has solved this problem for over a decade.
Can supermin replace dracut?
take care, Gerd
On Mo, 04.07.22 15:59, Gerd Hoffmann (kraxel@redhat.com) wrote:
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
Well, we didn't find any better tools, i.e. with all the verity stuff and signing in place. mkosi is just a wrapper around dnf, it's not really that smart... If it is fine building any kind of RPM-based image on fedora infra this shouldn't be any different...
we tried to make rh image builder people inetreested in that, but they weren't interested in that at all.
I don't think mkosi is a hard requirement for unified kernel images though.
No, it's not. mkosi is just a python script gluing all the dnf, gpt, fdisk, verity, signing stuff together. You can reimplement that.
Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no?
We want to build initrds from RPM, to make the reasonably reproducible and follow proper deps. It's a major facet of the project. magic build scripts trying to magically determine deps from ELF and config and whatnot is kind what we want to get away from.
The credentials logic can also be used to for example pass a root pw for the initrd in a safe way.
Does systemd-cryptenroll use this?
Use what precisely? the root pw? no, why would it?
or the credentials api? i mean, there's no direct hookup, but we don't really need it: from the service side credentials are just files in the file system, and we do support reading keys from that.
When getting the credentials for the encrypted root filesystem (or something else) from somewhere else, i.e. some attestation server such as https://keylime.dev/, how could that be integrated with systemd-creds best? Simply have the agent write to /run/credentials?
I don't know keylime. But note that service credentials can be read from a variety of sources: most prominently regular files on disk you specify via an fs path. Now one tweak here is that if you actually specify an AF_UNIX socket inode in the fs as fs path, then we'll connect to it, and read the credential data from it. This is a flexible way to plug anything you like into the service credential logic: all keylime has to do is bind a socket somewhere, with tight perms, and then whenever a connection comes in just write the credential data into the connection and close it right after.
My expectation would be that by default we'd just use the GPT auto discovery stuff and for "pet" systems maybe also encode the root device with a credntial, but for "cattle" systems not bother.
Yep.
Is there some fallback mechanism btw? Most cloud images have just four partitions: bios-boot, efi esp, boot and root. And the root filesystem is simply the largest partition ...
Actually, the implementation of the gpt auto logic (at least on some contexts) is somewhat tolerant: if the partitions are not properly tagged (i.e. use generic type uuids) but there's only a single one that would be a candidate, then it will be used as root fs. We refuse working that way though once you have two entirely generic partitions and we thus have no clue which it could be...
But why not just fix the cloud images to just use descriptive type uuids? that has no drawbacks, just benefits.
Lennart
-- Lennart Poettering, Berlin
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
we tried to make rh image builder people inetreested in that, but they weren't interested in that at all.
For initrd building or for cloud image building?
I don't think mkosi is a hard requirement for unified kernel images though.
No, it's not. mkosi is just a python script gluing all the dnf, gpt, fdisk, verity, signing stuff together. You can reimplement that.
Once the local configuration issues are solved it should be possible to run "dracut --no-hostonly" in koji + ship results instead of doing it on the installed host, no?
We want to build initrds from RPM, to make the reasonably reproducible and follow proper deps. It's a major facet of the project. magic build scripts trying to magically determine deps from ELF and config and whatnot is kind what we want to get away from.
Sure, that totally makes sense longer-term.
But I'm also trying to figure how far we can get without putting the initrd build process upside-down. Something along the lines of an (for starters optional) kernel-initrd subpackage with a "dracut --no-hostonly" generated initrd in it. When that is present on the installed system just use it instead of running dracut to build one.
But why not just fix the cloud images to just use descriptive type uuids? that has no drawbacks, just benefits.
Yea, need to figure how to do that. I guess step #1 is getting anaconda or blivet or whatever other tool anaconda uses for partitioning fixed. And I also guess it'll take a while given we have a 7 year old bug asking for that ...
take care, Gerd
On Di, 05.07.22 09:49, Gerd Hoffmann (kraxel@redhat.com) wrote:
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
we tried to make rh image builder people inetreested in that, but they weren't interested in that at all.
For initrd building or for cloud image building?
initrd building.
Lennart
-- Lennart Poettering, Berlin
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
Hi,
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-initr...
Hmm. Nice ideas (reproducible initrds, yay!), but it feels more like being at proof-of-concept state. mkosi going fetch stuff from the internet to generate the initrd is clearly a non-starter (maybe not that much of a problem when doing it in koji where the next fedora repo is only one network hop away).
A few experiments later. Using 'mkosi --use-host-repositories' greatly improves the situation. mkosi picks up the local repo config then and fetches stuff from my local mirror.
Going build unified kernel image (using 'man systemd-stub' instructions):
# build unified kernel echo "Unified Linux Kernel ${KVER}" > os-release objcopy --add-section .osrel=os-release \ --add-section .cmdline=/proc/cmdline \ --add-section .linux=/boot/vmlinuz-${KVER} \ --add-section .initrd=initrd_${KVER}.cpio.zstd \ \ --change-section-vma .osrel=0x20000 \ --change-section-vma .cmdline=0x30000 \ --change-section-vma .linux=0x2000000 \ --change-section-vma .initrd=0x3000000 \ \ /usr/lib/systemd/boot/efi/linuxx64.efi.stub \ /boot/efi/EFI/Linux/unified-${KVER}.efi
Booting that directly from the ovmf firmware menu works fine. Progress!
grub2 doesn't find it. Support not implemented?
Ok, lets try systemd-boot instead. Install. Chainload from grub for now:
root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg if [ "$grub_platform" = "efi" ]; then menuentry 'systemd boot loader' { chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi } fi
systemd-boot doesn't find it either. Double-checking. ESP mounted at /boot/efi. Directory looks fine to me:
root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux total 77832 -rwx------. 1 root root 79698816 Jul 6 15:36 unified-5.18.9-200.fc36.x86_64.efi
Any clues?
thanks, Gerd
On Mi, 06.07.22 16:13, Gerd Hoffmann (kraxel@redhat.com) wrote:
grub2 doesn't find it. Support not implemented?
afics grub2 upstream has no native support for boot loader spec stuff. (or has that changed?)
The fedora version of grub2 implements a flavour of type #1 boot loader spec entries (i.e. .conf entries), but not type #2 (i.e. unified kernels), iirc.
Ok, lets try systemd-boot instead. Install. Chainload from grub for now:
root@fedora ~/mkosi-initrd (main)# cat /boot/grub2/custom.cfg if [ "$grub_platform" = "efi" ]; then menuentry 'systemd boot loader' { chainloader (hd0,gpt1)/efi/systemd/systemd-bootx64.efi } fi
systemd-boot doesn't find it either. Double-checking. ESP mounted at /boot/efi. Directory looks fine to me:
root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux total 77832 -rwx------. 1 root root 79698816 Jul 6 15:36 unified-5.18.9-200.fc36.x86_64.efi
Any clues?
I am not a grub guy, haven't used it in a long time. But my educated guess is this: I think grub might load the chainloaded binary into memory itself, and then execute it from there, instead of invoking it directly from the ESP file system. This matters because if sd-boot is invoked from a synthetic file in memory we cannot derive the directory tree of the ESP from it, and thus not find boot loader entries.
Lennart
-- Lennart Poettering, Berlin
On Wed, Jul 06, 2022 at 05:12:20PM +0200, Lennart Poettering wrote:
On Mi, 06.07.22 16:13, Gerd Hoffmann (kraxel@redhat.com) wrote:
grub2 doesn't find it. Support not implemented?
afics grub2 upstream has no native support for boot loader spec stuff. (or has that changed?)
Nope. Which is a PITA when you want hack something in upstream grub because it wouldn't boot fedora without hacks.
The fedora version of grub2 implements a flavour of type #1 boot loader spec entries (i.e. .conf entries), but not type #2 (i.e. unified kernels), iirc.
Suspected that.
systemd-boot doesn't find it either. Double-checking. ESP mounted at /boot/efi. Directory looks fine to me:
root@fedora ~/mkosi-initrd (main)# ll /boot/efi/EFI/Linux total 77832 -rwx------. 1 root root 79698816 Jul 6 15:36 unified-5.18.9-200.fc36.x86_64.efi
Any clues?
I am not a grub guy, haven't used it in a long time. But my educated guess is this: I think grub might load the chainloaded binary into memory itself, and then execute it from there, instead of invoking it directly from the ESP file system. This matters because if sd-boot is invoked from a synthetic file in memory we cannot derive the directory tree of the ESP from it, and thus not find boot loader entries.
Adding a boot entry to the firmware to load sd-boot directly and take grub out of the chain doesn't change the situation.
take care, Gerd
It should be possible to load sd-boot directly, it picks up any kernel in /boot/EFI/linux for me. Try loading sd-boot directly from ovmf, skipping grub.
My expectation would be that by default we'd just use the GPT auto
discovery stuff
Existing Fedora installations do not follow the GPT auto discovery spec. Also, I think the existing system for the root device can still work, it is passed in the command line, not the initrd.
On Mo, 04.07.22 19:24, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
My expectation would be that by default we'd just use the GPT auto
discovery stuff
Existing Fedora installations do not follow the GPT auto discovery spec.
If it is desirable to automatically switch existing installations from "locally-genrated dracut mode" to "pre-build unified kernels mode", then make sure to encode the root fs uuid in a credential and place it next to the kernel.
Also, I think the existing system for the root device can still work, it is passed in the command line, not the initrd.
Well, we'd have to authenticate that kernel cmdline somehow. Which means doing TPM stuff before we switch to Linux kernel mode. i'd rather avoid that, since afaics this would boil down to linking a static copy of the TSS stack into an UEFI binary.
It's OK to modify your kernel cmdline if you really want, but if you want that level of tweaking then it's probably totally OK to just turn of Secureboot, at which point you can change it freely.
I am not convinced it must be a priority to allow arbitrary local kernel cmdline options even in the most locked down mode.
Lennart
-- Lennart Poettering, Berlin
On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Also, if users have "special" hardware, shouldn't they also have security.
if you need a special kernel cmdline to get your system to boot, then that's a bug in the kernel, and should be fixed there. Adding a kernel cmdline option is a local hack at best, executable only by the most technically savvy of users, and I think for those it's totally OK if you have to disable SecureBoot if you hack around.
Kernels should work universally, and if the don't do that out-of-the-box on some very new or very exotic hardware, then the right fix is not to expect users to be technical enough to set a kernel cmdline, but to fix the kernel to apply the fix automatically where needed. The kernel has plenty infrastructure for that.
Lennart
-- Lennart Poettering, Berlin
Lennart Poettering mzerqung@0pointer.de writes:
On Di, 05.07.22 01:44, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Also, if users have "special" hardware, shouldn't they also have security.
if you need a special kernel cmdline to get your system to boot, then that's a bug in the kernel, and should be fixed there. Adding a kernel cmdline option is a local hack at best, executable only by the most technically savvy of users, and I think for those it's totally OK if you have to disable SecureBoot if you hack around.
I think this overestimates the complexity required here. You follow the on-screen instructions to press 'e', arrow key to the end of the line, and type the parameters from the support forum or stackoverflow or wherever.
Kernels should work universally, and if the don't do that out-of-the-box on some very new or very exotic hardware, then the right fix is not to expect users to be technical enough to set a kernel cmdline, but to fix the kernel to apply the fix automatically where needed. The kernel has plenty infrastructure for that.
In an ideal world, perhaps. But kernel parameters are also used for things that have nothing to do with hardware, such as needing to drop to a root shell on boot to fix problems in early userspace (e.g., clobbered /etc/shadow).
Be well, --Robbie
On Mon, Jul 04, 2022 at 07:24:28PM -0000, Sharpened Blade via devel wrote:
My expectation would be that by default we'd just use the GPT auto
discovery stuff
Existing Fedora installations do not follow the GPT auto discovery spec. Also, I think the existing system for the root device can still work, it is passed in the command line, not the initrd.
command line is only slightly better than being baked into the initrd when it comes to using the TPM. The command line gets measured, so when each machine needs its individual root=UUID=<something> each machine has a different PCR value ...
root=LABEL=<something> is slightly better because it's the same for all machines, but labels are collected from all disks which are present on the system whereas auto discovery looks only at the disk the system booted from.
take care, Gerd
With virtual machines, nothing can actually be verified completely, the host running the vm can, 1) Modify the firmware to intercept anything the attacker wants, or 2) directly intercept things at the cpu level.
Once upon a time, Sharpened Blade sharpenedblade@proton.me said:
With virtual machines, nothing can actually be verified completely, the host running the vm can, 1) Modify the firmware to intercept anything the attacker wants, or 2) directly intercept things at the cpu level.
There are CPU extensions that I understand stop that, so that the hypervisor and VMs do not have to trust each other. That's part of the reason to secure the boot stack.
On Mon, Jul 04, 2022 at 07:20:32PM -0000, Sharpened Blade via devel wrote:
With virtual machines, nothing can actually be verified completely, the host running the vm can, 1) Modify the firmware to intercept anything the attacker wants, or 2) directly intercept things at the cpu level.
With SEV-SNP (amd) or TDX (intel) cpu extensions you can avoid that. You get launch measurement: Basically the cpu calculates a hash of the initial VM state and this can be verified later to make sure the system actually runs the firmware you want it run. The host also is not allowed to modify (or even see) guest state.
take care, Gerd
How can you know if this interface is not emulated, and you never talk to the real cpu.
On Tuesday, 5 July 2022 17:26:40 BST Sharpened Blade via devel wrote:
How can you know if this interface is not emulated, and you never talk to the real cpu
The TDX white papers address how this is meant to work - it's based around the same "measurement" concept as TPM measured boot (see https://bootlin.com/blog/ measured-boot-with-a-tpm-2-0-in-u-boot/ for an explanation).
While the VM itself cannot avoid being compromised by the hoster, if you emulate the TDX interface, you'll not be able to send the "correct" measurements with an Intel signature - the measurements that can be sent have either the wrong hash, or the wrong signature (similar applies to AMD's version, but with an AMD signature).
In turn, this means that you reduce your trust chain down to the CPU maker, because if the VM platform tampers with TDX trust chains, you can observe this and refuse to (e.g.) send the VM platform the encryption key it needs to unlock private data.
If it is really compromised, then you have to assume anything the vm sends you is fake. As far as the owner of guest knows, there could not even a a real vm, only a ssh shell that looks like it.
In a real situation, the guest owner would send the host owner a "starting disk" or ISO. Then the host would tell the trusted cpu to boot a iso that sends the signature to the host, and also boot a modified iso in a normal hypervisor, and emulate the trusted part of the cpu. When the normal hypervisor vm wants the signature, the signature of vm1 is returned. The system in the normal hypervisor could also just lie to any connections outside the host system, so even if it knows its backdoored, it still test the guest owner its not.
On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote:
If it is really compromised, then you have to assume anything the vm sends you is fake. As far as the owner of guest knows, there could not even a a real vm, only a ssh shell that looks like it.
In a real situation, the guest owner would send the host owner a "starting disk" or ISO. Then the host would tell the trusted cpu to boot a iso that sends the signature to the host, and also boot a modified iso in a normal hypervisor, and emulate the trusted part of the cpu. When the normal hypervisor vm wants the signature, the signature of vm1 is returned. The system in the normal hypervisor could also just lie to any connections outside the host system, so even if it knows its backdoored, it still test the guest owner its not.
This is a solved problem, and you need to read up on how remote attestation works in the presence of an attacker to understand fully how it's solved.
The core to the trick is that the CPU prevents the hypervisor from seeing into the state that belongs to the guest (measurements, memory content etc), unless the guest explicitly tells the CPU to share that memory. It does this using cryptographic primitives so that even an attacker who can monitor the DRAM bus externally to the CPU cannot see into guest state.
You can thus use key exchange protocols designed to work over a public channel (Diffie-Hellman for a simple example) to set up an encrypted channel between the guest and the remote system such that the hypervisor can only deny service - it cannot see into the channel, and thus cannot lie to the guest or its remote attestation service.
The same techniques are used in TLS to set up a secure channel between a service provider like https://start.fedoraproject.org/ and a user like my Fedora laptop
Once upon a time, Sharpened Blade sharpenedblade@proton.me said:
How can you know if this interface is not emulated, and you never talk to the real cpu.
That's like saying you can't know if https://www.google.com/ is Google because your computer only talks to AT&T.
That attack is a real thing, its called a mitm, but things use https now, so you would need a malicious CA.
Even if initrds are (somehow) signed, the kernel command line can still be modified, like adding `init=/usr/bin/bash`. Also, if everything is signed by fedora, then the user can not modify the command line. There is a lot of hardware that needs command line modifications to boot. Also, fedora would have to revoke signatures for every vulnerable kernel, or there is no real security. If those kernels signatures are revoked, then they wont boot even when they are the currently installed kernel and should be able to boot. If there is a way for a fedora signed kernel image to load a locally signed command line, then this would work much better.
However I think the initrd should be built on fedora infra and signed with fedora keys by default.
What about when the user has a custom kernel module, would there be a way for the user to use it.
On Mo, 04.07.22 19:18, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Even if initrds are (somehow) signed, the kernel command line can still be modified, like adding `init=/usr/bin/bash`.
Hmm? sd-stub refused any kernel cmdline passed in manually if SecureBoot is on. The kernel cmdline allows you to do pretty much anything you like with your system, hence in a locked down environment we cannot allow uncontrolled access to that.
Also, if everything is signed by fedora, then the user can not modify the command line. There is a lot of hardware that needs command line modifications to boot.
Like what?
Also, fedora would have to revoke signatures for every vulnerable kernel, or there is no real security. If those kernels signatures are revoked, then they wont boot even when they are the currently installed kernel and should be able to boot.
I think as long as we get rollback protection we should be fine. i.e. after a kernel has been deemed good and working for a bit, we can automatically cut off older kernels via TPM logic after a while. (this requires implementing a TPM policy against a counter stored in the TPM. This is not implemented yet in the TPM policies systemd supports, but can be expression in TPM2 policy language.)
If there is a way for a fedora signed kernel image to load a locally signed command line, then this would work much better.
Well, we could add that, but this would mean doing more complex TPM interactions from UEFI environment, and I'd rather not do that too much.
However I think the initrd should be built on fedora infra and signed with fedora keys by default.
What about when the user has a custom kernel module, would there be a way for the user to use it.
You can enroll multiple certificates for validation, if you like. i.e. if you want to sign your own modules, then enroll both the fedora and your own cert. You could use shim for that if you like.
Or alternatively, turn off secureboot if you don't want to set up your certs, and want to load hacky modules.
Lennart
-- Lennart Poettering, Berlin
On Di, 05.07.22 02:34, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Like what?
I know there are some efi implementations that need pcie_ports=compat. I also know that sometimes you need intel_iommu or amd_iommu=off.
Those are local hacks to get very new or very exotic hw to work without fixing the kernel properly. But it's not the way this *should* work. Instead, the kernel should detect these systems properly on its own, and make this work without adjusting the kernel cmdline. There's plenty infrastructure for that available in the kernel.
What you are doing with the above is a hack that should require highest privileges to do, and hence it's OK (not just OK, it's *good*) to disable SecureBoot for that while you make them.
Lennart
-- Lennart Poettering, Berlin
Another idea is to measure the initrd and the boot configuration, for example taking a hash of the grub configuration and initrd and extending a PCR register.
To make it work across upgrades, the grub configuration could be put into a git repository. Each commit hash is computed using the TPM and changes are appended to the repository. During boot, grub would extend the PCR, one time per commit, with the commit content. Grub would then execute the git working tree.
This makes it possible to, after a grub config change / kernel upgrade / dracut change etc. to precalculate the PCR values (as suggested on https://github.com/latchset/clevis/issues/366) that can then be used to bind luks passphrases.
On Fri, Jul 15, 2022 at 10:33:03AM -0000, Francois Rigault wrote:
Another idea is to measure the initrd and the boot configuration, for example taking a hash of the grub configuration and initrd and extending a PCR register.
That is already happening.
Problem with measuring the initrd is that we don't have fixed hashes for a given kernel version (due to generating the initrd on the installed system).
Problem with grub config measurements is that grub measures every config file line it processes, which is quite messy:
root@fedora ~# tpm2 eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep grub_cmd grub_cmd: search --no-floppy --fs-uuid --set=dev 5cc83bf9-c040-42d9-819e-99a16462d518 grub_cmd: set prefix=(hd0,gpt2)/grub2 grub_cmd: export (hd0,gpt2)/grub2 grub_cmd: configfile (hd0,gpt2)/grub2/grub.cfg grub_cmd: set pager=1 grub_cmd: [ -f (hd0,gpt2)/grub2/grubenv ] grub_cmd: load_env -f (hd0,gpt2)/grub2/grubenv grub_cmd: [ ] grub_cmd: set default=47c4701d41c0470992ce27741da89d4a-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64 grub_cmd: [ xy = xy ] grub_cmd: menuentry_id_option=--id grub_cmd: export menuentry_id_option grub_cmd: [ ] grub_cmd: serial --speed=115200 grub_cmd: terminal_input serial console grub_cmd: terminal_output serial console grub_cmd: [ xy = xy ] grub_cmd: set timeout_style=menu grub_cmd: set timeout=5 grub_cmd: [ -f (hd0,gpt2)/grub2/user.cfg ] grub_cmd: insmod increment grub_cmd: [ -n -a 1 = 0 ] grub_cmd: insmod part_gpt grub_cmd: insmod xfs grub_cmd: set root=hd0,gpt2 grub_cmd: [ xy = xy ] grub_cmd: search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 5cc83bf9-c040-42d9-819e-99a16462d518 grub_cmd: insmod part_gpt grub_cmd: insmod fat grub_cmd: set boot=hd0,gpt1 grub_cmd: [ xy = xy ] grub_cmd: search --no-floppy --fs-uuid --set=boot --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 8C55-9DE2 grub_cmd: [ -z ] grub_cmd: set kernelopts=root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8 ro rootflags=subvol=root console=ttyS0,115200 grub_cmd: insmod blscfg grub_cmd: blscfg grub_cmd: [ 1 = 1 -o 0 = 1 ] grub_cmd: set menu_hide_ok=1 grub_cmd: [ 1 = 1 ] grub_cmd: set boot_indeterminate=0 grub_cmd: set boot_success=0 grub_cmd: save_env boot_success boot_indeterminate grub_cmd: [ xy = xy ] grub_cmd: [ ] grub_cmd: [ efi = efi ] grub_cmd: menuentry UEFI Firmware Settings --id uefi-firmware { grub_cmd: [ -f (hd0,gpt2)/grub2/custom.cfg ] grub_cmd: source (hd0,gpt2)/grub2/custom.cfg grub_cmd: [ efi = efi ] grub_cmd: menuentry systemd boot loader { grub_cmd: load_video grub_cmd: [ xy = xy ] grub_cmd: insmod all_video grub_cmd: set gfxpayload=keep grub_cmd: insmod gzio grub_cmd: linux (hd0,gpt2)/vmlinuz-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64 root=UUID=cb3e8fe8-2e6c-4f12-bd3b-f76fc1448bd8 ro rootflags=subvol=root console=ttyS0,115200 grub_cmd: initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img root@fedora ~#
take care, Gerd
indeed, this is why a proposal is to change the way grub measure things.
For example introducing a new PCR, for example PCR10, and a new command, "extend", that replay a command into the PCR without actually executing it. This would mean for your above example, if we only limit to the last line, you would boot first your server with
initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img
and you read a value of PCR10 = p0 Following an upgrade, you would unbind the luks decryption, run _tpm2_pcrextend initrd (hd0,gpt2)/init.fc37.img which brings PCR10 = p1, then you can rebind the luks decryption key with PCR10 (and others)
The grub configuration now looks like extend initrd (hd0,gpt2)/initramfs-5.19.0-0.rc6.20220714git4a57a8400075.49.kraxel.4.fc36.x86_64.img initrd (hd0,gpt2)/init.fc37.img
Upon next boot, grub execute the extend command bringing PCR10 to p0, then measure the new "initrd (hd0,gpt2)/init.fc37.img" into it, bringing PCR10 to p1, so decryption can happen automatically.
The checksum of initrd can also be checked using grub with the hashsum command.
(I realize this idea is not trivial at all. Nevertheless here's a build of grub with a patch that implement part of that https://koji.fedoraproject.org/koji/taskinfo?taskID=89600764)
On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel@redhat.com) wrote:
On Fri, Jul 15, 2022 at 10:33:03AM -0000, Francois Rigault wrote:
Another idea is to measure the initrd and the boot configuration, for example taking a hash of the grub configuration and initrd and extending a PCR register.
That is already happening.
Problem with measuring the initrd is that we don't have fixed hashes for a given kernel version (due to generating the initrd on the installed system).
Problem with grub config measurements is that grub measures every config file line it processes, which is quite messy:
The very newest kernels measure all initrds on their own into PCR 9 these days. It should be the only thing measured into PCR 9, hence you can pre-calculate what you are going to see in the PCR easily if you have the initrds.
I also intend to change sd-stub to measure the kernel it is prefixed to and the other stuff it makes use of from the PE image into a separate PCR, that is otherwise not used so far. i.e. PCR 11 or so. This stuff could then also be easily pre-calculated: if you have the kernel image you know what the PCR value will be.
Once we have that, we can relatively easily express policies for TPM resources that bind to kernel + initrd, and pre-calculate those easily at build time (or at install time in case of dynamic initrds), without any need for rebooting into the new setup and then looking at the measured hsah values.
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
The next step is then to extend the kernel PE images, to also contain the PCR hsah signatures appropriate for the kernel. That would make it nice and simple to deploy new kernels in a robust fashion so that they always carry enough metainfo so that TPM policies can be written that match the vendor.
(the model isn't perfect yet though: tpm policies built that way need some rollback protection, i.e. some counter kept in tpm nvram that can only increase, and whose cutoff value is also signed along with the PCR hashes, so that one can invalidate old kernels if needed, without having to invalidate signatures as a whole)
Lennart
-- Lennart Poettering, Berlin
On Mon, Jul 18, 2022 at 05:03:53PM +0200, Lennart Poettering wrote:
On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel@redhat.com) wrote:
Problem with measuring the initrd is that we don't have fixed hashes for a given kernel version (due to generating the initrd on the installed system).
The very newest kernels measure all initrds on their own into PCR 9 these days. It should be the only thing measured into PCR 9, hence you can pre-calculate what you are going to see in the PCR easily if you have the initrds.
That is the big if. If you have the initrds.
I've hacked up the kernel rpm to also build a initrd (targeting virtual machines for starters) and shipping that as (optional) sub-rpm ...
https://src.fedoraproject.org/fork/kraxel/rpms/kernel/commits/initrd (proof-of-concept local builds only so far, probably needs fixes for build dependencies to actually work in koji).
... exactly to address that. Known initrd with known hashes, to allow pre-calculating the PCR values.
at build time (or at install time in case of dynamic initrds), without
At build time is much better IMHO. It's more robust. It's easier to manage. The PCR values are useful for third parties (for example remote attestation services) because all machines with a given kernel version run the same initrd.
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
take care, Gerd
On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote:
That is the big if. If you have the initrds.
I've hacked up the kernel rpm to also build a initrd (targeting virtual machines for starters) and shipping that as (optional) sub-rpm ...
FWIW, every rpm-ostree based system defaults to shipping a server side generated initramfs today.
On Tue, Jul 19, 2022 at 11:02:32AM -0400, Colin Walters wrote:
On Tue, Jul 19, 2022, at 10:15 AM, Gerd Hoffmann wrote:
That is the big if. If you have the initrds.
I've hacked up the kernel rpm to also build a initrd (targeting virtual machines for starters) and shipping that as (optional) sub-rpm ...
FWIW, every rpm-ostree based system defaults to shipping a server side generated initramfs today.
Noticed that (and I guess this is the reason for dracut scripts already checking whenever /lib/modules/$version/initrd exists).
Where does that build happen? Must be outside the kernel rpm build process, so probably when generating the ostree?
Any plans for switching to unified kernel images, to have the initrd covered by secure boot signing?
take care, Gerd
On Wed, Jul 20, 2022, at 4:44 AM, Gerd Hoffmann wrote:
Where does that build happen? Must be outside the kernel rpm build process, so probably when generating the ostree?
Exactly. We also run all %post scripts server side too for example.
You can see the logs for this at e.g. https://kojipkgs.fedoraproject.org/compose/updates/Fedora-36-updates-2022072... for aarch64 silverblue 36. And at e.g. https://jenkins-fedora-coreos-pipeline.apps.ocp.fedoraproject.org/job/build/... for a Fedora CoreOS testing-devel build (that also builds update disk images).
(One profound difference between these two things right now is that with Fedora CoreOS we actually test the ostree image before shipping it to users, for example booting the resulting update in qemu, including the server side generated dracut image etc. in a tightly integrated build/test setup, which Koji...doesn't.)
Any plans for switching to unified kernel images, to have the initrd covered by secure boot signing?
There's a lot of active related debate on things related to this; but it's really important to understand that with ostree in general it is a top level goal to support "open" Linux systems where you are root on your computer - the same way as yum based systems. While we ship as an image by default, it is intentional that you can e.g. change the initramfs locally (you can run `rpm-ostree initramfs --enable` to dynamically switch to client-side dracut runs) or kernel command line arguments or more generally inject persistent, privileged code.
I for sure want to support people creating their own actually "sealed"/"locked down" systems, particularly for e.g. IoT type setups and support for "unified" style kernel images is likely part of that.
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel@redhat.com) wrote:
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
Yupp.
Zbigniew and I are working on making pre-built initrds for general purpose distros a reality, i.e. finding a way between keeping things reasonably modular but also pre-generated, immutable, pre-measurable, and thus have a tight trust chain at boot. We'll do two talks about that at Linux Plumbers Conference later this year.
Lennart
-- Lennart Poettering, Berlin
On 7/19/22 12:13, Lennart Poettering wrote:
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel@redhat.com) wrote:
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
Yupp.
Zbigniew and I are working on making pre-built initrds for general purpose distros a reality, i.e. finding a way between keeping things reasonably modular but also pre-generated, immutable, pre-measurable, and thus have a tight trust chain at boot. We'll do two talks about that at Linux Plumbers Conference later this year.
Lennart
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
On Wed, Jul 20, 2022 at 03:06:46PM -0400, Demi Marie Obenour wrote:
On 7/19/22 12:13, Lennart Poettering wrote:
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel@redhat.com) wrote:
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
Yupp.
Zbigniew and I are working on making pre-built initrds for general purpose distros a reality, i.e. finding a way between keeping things reasonably modular but also pre-generated, immutable, pre-measurable, and thus have a tight trust chain at boot. We'll do two talks about that at Linux Plumbers Conference later this year.
Lennart
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
That's probably going to be useful for Qubes OS too, indeed.
It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too.
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek@invisiblethingslab.com) wrote:
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
That's probably going to be useful for Qubes OS too, indeed.
It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too.
So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot.
I think finding the root fs is something that should be solved without a dynamic kernel command line. I see three options:
1. Don't specify the root fs at all, let systemd-gpt-auto-generator find it for you. It does that by default: it looks for a properly tagged root partition in the GPT partition table the ESP used to boot was found on.
2. If you use a Verity-enabled root fs, then pin the root fs via its top-level hash on the kernel cmdline, and build that one into the unified kernel image. systemd-gpt-auto-generator helps you with that, if you use roothash= on the kernel cmdline, then this is entirely enough for it to find the partitions, and configure them as dm-verity.
3. Use the new credentials logic in systemd, that allows encrypted/authenticated credentials, bound to the TPM2. "Credentials" are just data blobs that you can pass from external sources into a system and from a system into services. These credentials can be optionally encrypted+authenticated against a symmetric key in the TPM. (for details see: https://systemd.io/CREDENTIALS). One data source for these credentials is *.cred files in the directory you put the kernel image in, if you use systemd-stub. The idea would then be: wrap information where to find the root fs in a credential, encrypt/sign it with the key from the TPM, place the result int the ESP. sd-stub then picks it up, passes it to the booted kernel/initrd. The initrd then reads it, decrypts/authenticates it, and then uses the info to mount the rootfs.
Lennart
-- Lennart Poettering, Berlin
On 7/20/22 16:20, Lennart Poettering wrote:
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek@invisiblethingslab.com) wrote:
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
That's probably going to be useful for Qubes OS too, indeed.
It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too.
So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot.
This is not a sufficient solution, as it creates an unnecessary security risk. I have had more than one occasion where my system was unbootable and I had to rescue it, either by using an installation image or by editing the kernel command line. Disabling secure boot would allow this, but it also means that *any* code might run, which is not wanted. What I want is to be able to authenticate as an authorized superuser, and know that the only code that will be able to run is code that would have run anyway, code involved in the recovery mechanism, and code that I have specifically entered or caused to be run. There is a huge difference between “anything at all can run” and “an authenticated and authorized superuser can provide additional code to be run”.
On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour@gmail.com) wrote:
So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot.
This is not a sufficient solution, as it creates an unnecessary security risk. I have had more than one occasion where my system was unbootable and I had to rescue it, either by using an installation image or by editing the kernel command line. Disabling secure boot would allow this, but it also means that *any* code might run, which is not wanted. What I want is to be able to authenticate as an authorized superuser, and know that the only code that will be able to run is code that would have run anyway, code involved in the recovery mechanism, and code that I have specifically entered or caused to be run. There is a huge difference between “anything at all can run” and “an authenticated and authorized superuser can provide additional code to be run”.
The thing is: if you want to allow making the kernel command line controllable by the user but still protect it cryptographically, then you need to authenticate it before passing control to the kernel. For example in sd-stub, i.e. the UEFI stub code that runs in UEFI mode, before ExitBootServices() is called.
But authenticating that is messy, because you need to authenticate it against something, i.e. user password (i.e. interactivity at each boot), or TPM. Both is very messy (because it either takes non-interactive boot away, or means embeddeding a TPM stack of some form into sd-stub, because UEFI will only give you access to the TPM in a bytestream, not with high-level commands).
Hence, I am not convinved the benefit really outweighs the effort here. Modifying your kernel command line is invasive, and hackish, and hence I think it's OK to leave it out of the model.
Lennart
-- Lennart Poettering, Berlin
On 7/22/22 05:40, Lennart Poettering wrote:
On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour@gmail.com) wrote:
So, in my view of the world, the kernel command line is fixated in the unified kernel image (if you use systemd-stub, this already happens if a .cmdline PE section exists, and SecureBoot is on). If you want to override it, then turn off SecureBoot.
This is not a sufficient solution, as it creates an unnecessary security risk. I have had more than one occasion where my system was unbootable and I had to rescue it, either by using an installation image or by editing the kernel command line. Disabling secure boot would allow this, but it also means that *any* code might run, which is not wanted. What I want is to be able to authenticate as an authorized superuser, and know that the only code that will be able to run is code that would have run anyway, code involved in the recovery mechanism, and code that I have specifically entered or caused to be run. There is a huge difference between “anything at all can run” and “an authenticated and authorized superuser can provide additional code to be run”.
The thing is: if you want to allow making the kernel command line controllable by the user but still protect it cryptographically, then you need to authenticate it before passing control to the kernel. For example in sd-stub, i.e. the UEFI stub code that runs in UEFI mode, before ExitBootServices() is called.
But authenticating that is messy, because you need to authenticate it against something, i.e. user password (i.e. interactivity at each boot), or TPM. Both is very messy (because it either takes non-interactive boot away, or means embeddeding a TPM stack of some form into sd-stub, because UEFI will only give you access to the TPM in a bytestream, not with high-level commands).
Hence, I am not convinved the benefit really outweighs the effort here. Modifying your kernel command line is invasive, and hackish, and hence I think it's OK to leave it out of the model.
What I would really like is to boot normally by default, but allow the user to break into a rescue mode by pressing a key at a certain point during boot. After authenticating, the user would be able to select between the last N installed kernels (kernel/hypervisor combos for Xen users) and would also be able to select a rescue mode. One might decide to allow booting the previous kernel without authentication if the most recent (newly installed) kernel has not yet booted successfully.
Something similar can be done with grub, but grub is extremely complex and has a slew of vulnerabilities. I would like a simpler and safer solution.
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
Hence, I am not convinved the benefit really outweighs the effort here. Modifying your kernel command line is invasive, and hackish, and hence I think it's OK to leave it out of the model.
It may be invasive or hackish, but sometimes it is absolutely necessary to getting a functional system. There are many valid uses, such as setting needed hardware parameters and setting the kernel console.
On 7/22/22 08:26, Chris Adams wrote:
Once upon a time, Lennart Poettering mzerqung@0pointer.de said:
Hence, I am not convinved the benefit really outweighs the effort here. Modifying your kernel command line is invasive, and hackish, and hence I think it's OK to leave it out of the model.
It may be invasive or hackish, but sometimes it is absolutely necessary to getting a functional system. There are many valid uses, such as setting needed hardware parameters and setting the kernel console.
Exactly! And there are times when this needs to be changed after the system has already been installed. There is no substitute for being able to authenticate and then enter kernel parameters. The simplest way to implement this would be kexec().
On 7/20/22 15:55, Marek Marczykowski-Górecki wrote:
On Wed, Jul 20, 2022 at 03:06:46PM -0400, Demi Marie Obenour wrote:
On 7/19/22 12:13, Lennart Poettering wrote:
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel@redhat.com) wrote:
Moreover, this allows us to implemented TPM policies that bind to signatures of PCR hashes, instead of the literal hash values. That makes the measurements a *million* times more useful, since we loose the brittleness on updates: if the expected PCR values can be pre-calculated by the vendor, and then be signed, then an update won't invalidate the policies anymore.
Another case which requires creating initrds at build time.
Yupp.
Zbigniew and I are working on making pre-built initrds for general purpose distros a reality, i.e. finding a way between keeping things reasonably modular but also pre-generated, immutable, pre-measurable, and thus have a tight trust chain at boot. We'll do two talks about that at Linux Plumbers Conference later this year.
Lennart
I wonder if Qubes OS could use any of this work. It seems that it would be incredibly useful, at least if it supported systems using the Xen hypervisor.
That's probably going to be useful for Qubes OS too, indeed.
It would be even better, if kernel cmdline could be pre-measured too, as many kernel parameters may affect overall system security (like disabling iommu). There is currently one major issue with this: finding root filesystem. If the "initrd cmdline" could be separate from "kernel cmdline", then one could include pre-measured safe kernel cmdline (perhaps even hardcoded into kernel binary), while still being able to instruct initrd where to look for the root fs. Of course, initrd would need to be careful about parsing this piece of information (probably having some allowlist of options allowed in this case), but that's a huge improvement already. There were few other ideas for this problem in this very thread too.
One option is to not require an initrd commandline, and instead install the system in such a way that the root filesystem can be discovered automatically. systemd’s discoverable partition specification might help here. Another approach would be to use the fact that everything after `--` gets passed to init, which can treat it as untrusted. This assumes that Linux treats that part as untrusted too, but this should not be too hard to ensure. It might be good to scrub that part from /proc/cmdline, though.
Would pre-building the initrds mean all users have to use the same partition layout. If that happened, than many people dual boot setups will not work
On Di, 19.07.22 21:16, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
Would pre-building the initrds mean all users have to use the same partition layout. If that happened, than many people dual boot setups will not work
No, it dos not mean that.
Lennart
-- Lennart Poettering, Berlin
devel@lists.stg.fedoraproject.org
-
Chris Adams -
Chris Murphy -
Colin Walters -
Daniel P. Berrangé -
David Airlie -
David Howells -
Demi Marie Obenour -
Dominique Martinet -
Florian Weimer -
Francois Rigault -
Gerd Hoffmann -
Lennart Poettering -
Marek Marczykowski-Górecki -
Michael Catanzaro -
Neal Gompa -
Petr Pisar -
Richard W.M. Jones -
Robbie Harwood -
Roberto Ragusa -
Sharpened Blade -
Simon Farnsworth -
Vitaly Zaitsev