enable Linux kernel gpg verification in grub and/or enable EFI Secure Boot for Qubes / Xen guests

[adrelanos]

security-misc (#1885) will allow loading signed kernel modules by default / disallow kernel module loading by default.

Next logical step seems to be enable Linux kernel gpg verification in grub and/or enable EFI Secure Boot for Qubes / Xen guests.

EFI seems possible for Xen guests as per: https://wiki.xen.org/wiki/OVMF

Couldn't figure out if Secure Boot is possible for Xen guests?

Even if Secure Boot is not possible yet, can we enable Linux kernel gpg verification in grub?

#4371 is about secure boot support on the host. I.e. when installing Qubes on real hardware. This ticket is about Qubes guest VMs.

Related thread:
https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894

[marmarek]

There is no UEFI / OVMF for PVH domains yet, but it should be there soon (there are patches on xen-devel already going through multiple review iterations). As for Secure Boot it isn't there yet - there is an implementation with a crucial part (variables store) closed source (Citrix / Xen Server), but should be easy to replicate. Not sure about it's compatibility with PVH (it was done specifically for HVM domains with Windows inside).

That said, can you explain what threats would kernel verification mitigate? I see all of it as a mitigations against malicious /boot modifications, which template-based VM can't do as /boot is not persistent and /rw isn't accessed at that point yet. So, it sounds like a complexity without any real value in our case.
The only thing that could improve anything is requiring module signatures (would be much easier in R4.1, where we don't need external u2mfn module anymore).

[adrelanos]

That's a good question.

Seems mostly useful for (HVM) StandaloneVM?

TemplateBasedVMs:

• Protects Xen similar to Automate vm sudo authorization setup #2695 - even root could not (easily) replace any kernel and use it to attack Xen for VM breakout? (Also no kexec into unsigned kernel, right?)
• Defense in depth in case someone ever figures out how to boot from /rw?

TemplateVMs: makes installation of malicious kernel much less likely. Even if there is ever such an epidemic, it would spare Qubes users.

[marmarek]

Seems mostly useful for (HVM) StandaloneVM?

Yes.

TemplateBasedVMs: * Protects Xen similar to #2695 - even root could not (easily) replace any kernel and use it to attack Xen for VM breakout? (Also no kexec into unsigned kernel, right?)

Replacing a kernel at runtime vs replacing /boot files are different things. The former would need to be prevented independently of the latter. This applies to a ton of interfaces, including loading modules /dev/mem, kexec and others. This is what kernel "lockdown" feature is about (it didn't make it into Linux 5.3).

* Defense in depth in case someone ever figures out how to boot from /rw?

In theory it could be. In practice /rw / private volume isn't touched there at all (not mounted etc), so I'd say it's pretty hard to do. BTW this is where dom0-provided kernel is better, because not only /rw isn't looked at, but no other VM storage volume is looked either.

TemplateVMs: makes installation of malicious kernel much less likely. Even if there is ever such an epidemic, it would spare Qubes users.

If you consider a threat model where distribution kernel package is compromised, you could probably also assume any other package compromised too. In which case, having not compromised kernel doesn't help that much.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[iprid23]

Hm, how about a different solution. Since we're using lvm and it let's us do snapshots, why not just start a scan vm and attach a snapshot of the suspected VM as read-only block device. Then we can for example check for malicious shell scripts and also for malicious kernel modules, kernel, etc. It might even be simpler to just check for files which are not signed assuming we can get files inside RPMs signed(GPG), then normally speaking for example: /bin, /usr/bin, /lib, etc. should not have files that are not signed unless the user modified those files. So imagine we just require all binaries to be signed, including shell scripts. Split GPG is perfect because the user has to sign a shell script before executing it in an interactive way.

Thinking about it, it's most useful to do this for template vm's. Basically the idea is to only put in trusted stuff. So you compile your stuff, sign it and then pass it to the template vm.

[adrelanos]

Sounds rather separate than replacement.

[adrelanos]

I had in mind here malware which attempts to gain persistence / rootkit by modifying the kernel. Not coming from malicious distribution repositories. "Just exploit" -> /etc/kernel/postinst.d/ folder hook -> malicious kernel modification to gain rootkit and persistence. Even just removing more and more rootkit abilities is worth it since it makes malware more visible, more easily detected and security issues closed.

Of course, after I said "Just exploit", malware has a lot other options to gain persistence. But a hypothetical category of malware not specifically targeting Qubes would be excluded.

Replacing files in /boot would get a lot harder. In future a combination of lockdown (non-replaceable kernel during runtime) plus Secure Boot (non-replaceable in /boot) could lead to help protecting Xen since no custom kernel can be used to attack Xen.

A related question is are non-perfect defenses, that keep off-the-shelf malware ineffective in Qubes worth it if that Malware would succeed anyhow if it was specifically targeting Qubes to work around these defenses. I think yes. Even though non-perfect, as end result less users will have their data leaked, and be thankful for that.

[madaidan]

In future a combination of lockdown (non-replaceable kernel during runtime)

The only way I know of replacing a kernel during runtime is with kexec which can be disabled by setting kernel.kexec_load_disabled=1 with sysctl. I don't see how lockdown will help with this further.

[marmarek]

The only way I know of replacing a kernel during runtime is with kexec which can be disabled by setting kernel.kexec_load_disabled=1 with sysctl. I don't see how lockdown will help with this further.

Unfortunately, this is very optimistic but untrue assumption. Indeed kexec is the only "proper" interface for replacing the kernel in runtime. But it there are multiple mechanisms that could be abused for that purpose. It's getting offtopic here, if you want to read more, see https://lwn.net/Articles/736910/