3:54 p.m.
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.
2:47 a.m.
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?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:56 a.m.
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.
--
Roberto Ragusa mail at robertoragusa.it
3:14 p.m.
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
7:43 p.m.
On Sat, Jun 25, 2022 at 4:14 PM Demi Marie Obenour
<demiobenour(a)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!
2:55 a.m.
* 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
3:32 a.m.
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
3:49 a.m.
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(a)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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:46 a.m.
On Mon, Jun 27, 2022 at 4:49 AM Daniel P. Berrangé <berrange(a)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(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
6:59 a.m.
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(a)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(a)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-isolat...
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:12 a.m.
On Mon, Jun 27, 2022 at 7:59 AM Daniel P. Berrangé <berrange(a)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(a)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(a)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-isolat...
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.
--
真実はいつも一つ！/ Always, there's only one truth!
7:31 a.m.
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(a)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(a)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(a)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-isolat...
>
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:34 p.m.
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer <fweimer(a)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.
--
Chris Murphy
2:15 p.m.
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.
2:16 p.m.
The latest akmods version can automatically sign kernel modules, it could even be enabled
by default.
2:18 p.m.
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.
2:19 p.m.
Akmods can automatically sign kernel modules, its just a few commands and then every
version will be signed.
2:25 p.m.
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.
2:27 p.m.
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.
2:47 p.m.
On 6/27/22 13:34, Chris Murphy wrote:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer
<fweimer(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1:42 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:45 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:26 a.m.
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:12 a.m.
On Tue, Jun 28, 2022 at 9:27 AM Daniel P. Berrangé <berrange(a)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
6:18 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:20 a.m.
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(a)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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
6:21 a.m.
* Chris Murphy:
On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer
<fweimer(a)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
10:50 a.m.
Demi Marie Obenour <demiobenour(a)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(a)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
11:10 a.m.
On 6/28/22 07:21, Florian Weimer wrote:
* Chris Murphy:
> On Mon, Jun 27, 2022 at 1:56 AM Florian Weimer <fweimer(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1:45 p.m.
It would be stored with permissions for only root to read it, and you disk should be
encrypted, or none of this matters.
2:19 p.m.
Sharpened Blade via devel <devel(a)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
2:27 p.m.
Sharpened Blade via devel <devel(a)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
4:32 p.m.
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.
1:15 a.m.
V Tue, Jun 28, 2022 at 08:27:16PM +0100, David Howells napsal(a):
Sharpened Blade via devel <devel(a)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
2:11 p.m.
Also, can it be fixed so adding the --uefi flag to dracut works with the default
generation scripots
3:39 p.m.
On Mon, Jun 27, 2022 at 6:33 PM Gerd Hoffmann <kraxel(a)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.
1:30 a.m.
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(a)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
3:31 a.m.
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
2:37 p.m.
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.
2:42 a.m.
On So, 19.06.22 20:54, Fedora Development ML (devel(a)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
2:55 a.m.
On Sa, 25.06.22 20:43, Neal Gompa (ngompa13(a)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
3:13 a.m.
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel(a)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
3:19 a.m.
On 7/4/22 04:13, Lennart Poettering wrote:
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel(a)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?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
3:30 a.m.
On Mon, Jul 04, 2022 at 10:13:23AM +0200, Lennart Poettering wrote:
On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel(a)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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:33 a.m.
On Mo, 04.07.22 04:19, Demi Marie Obenour (demiobenour(a)gmail.com) wrote:
On 7/4/22 04:13, Lennart Poettering wrote:
> On Fr, 01.07.22 08:30, Gerd Hoffmann (kraxel(a)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
3:35 a.m.
On Mo, 04.07.22 09:30, Daniel P. Berrangé (berrange(a)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
4:32 a.m.
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
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1075288
4:55 a.m.
On Mo, 04.07.22 11:32, Gerd Hoffmann (kraxel(a)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-in...
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
8:59 a.m.
Hi,
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
2:18 p.m.
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.
2:20 p.m.
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.
2:27 p.m.
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.
2:38 p.m.
Once upon a time, Sharpened Blade <sharpenedblade(a)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.
--
Chris Adams <linux(a)cmadams.net>
4:25 p.m.
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-in...
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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
nbdkit - Flexible, fast NBD server with plugins
https://gitlab.com/nbdkit/nbdkit
4:50 p.m.
On Mo, 04.07.22 19:18, Fedora Development ML (devel(a)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
4:57 p.m.
On Mo, 04.07.22 19:24, Fedora Development ML (devel(a)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
5:08 p.m.
On Mo, 04.07.22 15:59, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-in...
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
5:14 p.m.
On Mo, 04.07.22 19:27, Fedora Development ML (devel(a)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
5:48 p.m.
On Mon, Jul 4 2022 at 09:55:20 AM +0200, Lennart Poettering
<mzerqung(a)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
6:31 p.m.
New subject: rpm signing keys (Was: Suggestion: Use a unified kernel image by
default in the future.)
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
2:34 a.m.
On Di, 05.07.22 01:44, Fedora Development ML (devel(a)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
2:36 a.m.
On Di, 05.07.22 02:34, Fedora Development ML (devel(a)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
2:49 a.m.
Hi,
> >
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-in...
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
2:52 a.m.
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-in...
>
> 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
3:01 a.m.
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
3:08 a.m.
On Di, 05.07.22 09:49, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
Hi,
> > >
https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-in...
>
> 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
3:08 a.m.
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
11:26 a.m.
How can you know if this interface is not emulated, and you never talk to the real cpu.
12:20 p.m.
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.
--
Simon Farnsworth
12:49 p.m.
Lennart Poettering <mzerqung(a)0pointer.de> writes:
On Di, 05.07.22 01:44, Fedora Development ML
(devel(a)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
1:19 p.m.
Once upon a time, Sharpened Blade <sharpenedblade(a)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.
--
Chris Adams <linux(a)cmadams.net>
9:13 a.m.
On Mon, Jul 04, 2022 at 03:59:25PM +0200, Gerd Hoffmann wrote:
Hi,
> https://raw.githubusercontent.com/keszybz/mkosi-initrd-talk/main/mkosi-in...
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
10:12 a.m.
On Mi, 06.07.22 16:13, Gerd Hoffmann (kraxel(a)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
1:54 p.m.
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.
4:49 a.m.
On Wed, Jul 06, 2022 at 05:12:20PM +0200, Lennart Poettering wrote:
On Mi, 06.07.22 16:13, Gerd Hoffmann (kraxel(a)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
1:09 p.m.
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.
1:37 p.m.
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.
1:37 p.m.
That attack is a real thing, its called a mitm, but things use https now, so you would
need a malicious CA.
4:12 p.m.
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
7:25 a.m.
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
--
Simon Farnsworth
5:33 a.m.
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.
7:52 a.m.
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
9:16 a.m.
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)
10:03 a.m.
On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel(a)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
9:15 a.m.
On Mon, Jul 18, 2022 at 05:03:53PM +0200, Lennart Poettering wrote:
On Mo, 18.07.22 14:52, Gerd Hoffmann (kraxel(a)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
10:02 a.m.
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.
11:13 a.m.
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel(a)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
4:16 p.m.
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
4:44 p.m.
On Di, 19.07.22 21:16, Fedora Development ML (devel(a)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
3:44 a.m.
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
10:51 a.m.
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-2022...
for aarch64 silverblue 36. And at e.g.
https://jenkins-fedora-coreos-pipeline.apps.ocp.fedoraproject.org/job/bui...
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.
2:06 p.m.
On 7/19/22 12:13, Lennart Poettering wrote:
On Di, 19.07.22 16:15, Gerd Hoffmann (kraxel(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
2:55 p.m.
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(a)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.
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
3:20 p.m.
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki (marmarek(a)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
7:31 p.m.
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(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
7:48 p.m.
On 7/20/22 16:20, Lennart Poettering wrote:
On Mi, 20.07.22 21:55, Marek Marczykowski-Górecki
(marmarek(a)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”.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
4:40 a.m.
On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour(a)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
5:29 a.m.
On 7/22/22 05:40, Lennart Poettering wrote:
On Mi, 20.07.22 20:48, Demi Marie Obenour (demiobenour(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
7:26 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)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.
--
Chris Adams <linux(a)cmadams.net>
7:56 a.m.
On 7/22/22 08:26, Chris Adams wrote:
Once upon a time, Lennart Poettering <mzerqung(a)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().
--
Sincerely,
Demi Marie Obenour (she/her/hers)
637
days inactive
670
days old
103 comments
22 participants
participants (22)
-
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