On: OpenBSD Will Get Unique Kernels on Each Reboot

[perlgeek]

If the kernel image is different each time, you can't verify its integrity through a checksum.

I'm curious to hear from people working in infosec: is that real problem? How do you see the tradeoff?

[clarry → perlgeek]

I haven't noticed any boot time checksum verification on Linux or OpenBSD in the past 15 years. If it's there, I've missed it. But it doesn't seem like this change introduces a new problem. Secure boot springs to mind, but that's something you probably have to disable anyway to run OpenBSD...

Think about this angle: if you're concerned about infosec, and there is a malicious actor with the capability to replace your kernel (which you don't do unless you're root), you do have a real problem. Even if the kernel were verified at boot time, that same actor should have countless other attack vectors.

But it's something worth considering if a tursted chain from machine firmware all the way to the application level is established. It's not there yet.

What is the solution when you need to upgrade some kernel or program and the new version has a different cheksum? I don't see why that same solution, whatever it is, wouldn't work in the relinking case.

[danieldk → clarry]

I haven't noticed any boot time checksum verification on Linux or OpenBSD in the past 15 years.

Some Linux distributions support kernel and kernel module signature verification in combination with secure boot. As far as I understand, RHEL does this automatically when secure boot is enabled:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

https://wiki.gentoo.org/wiki/Signed_kernel_module_support

[snuxoll → danieldk]

AFAIK ANY distribution that supports secure boot does this, it's entirely pointless to sign the bootloader and kernel but then allow arbitrary kmod's to load in and harm your trusted system.

[jopsen → snuxoll]

I disabled secure boot on ubuntu because I couldn't get the virtualbox kernel module... So pretty sure the modules have to be signed.

Anyways, with Lenovo who is to say they didn't leak their private key out shear incompetence :)

[prashast → jopsen]

I faced the same issue. Though disabling secure boot just to get the vbox driver running isn't the best idea. There are quite many detailed tutorials that list how you can sign the vbox modules and it won't take that much time, I promise. If the kernel devs are providing us with a security mechanism, might as well use it. :)

[Ded7xSEoPKYNsDd → perlgeek]

You could just feed the individual kernel symbols in a canonical order (i.e. sorted) to the checksum algorithm. It's a bit more involved, but since boot loaders like Grub already have ELF parsers, it shouldn't be too hard.

[hobarrera → perlgeek]

You could generate a checksum each time you generate a new kernel. If you need some pre-kernel checksum validation, that might be a problem though.

[clarry → hobarrera]

In fact OpenBSD already generates a checksum for each kernel.

[dgroshev → perlgeek]

According to [1],

> "At boot time, a unique kernel is built and installed for the next boot"

Therefore, if the building code is itself trusted it can make a checksum and sign it. So each boot can verify the next boot, in a blockchain-ish way.

[1]: https://news.ycombinator.com/item?id=14711983

[fooker → dgroshev]

How does this help though?

If you are in a position to replace the kernel, can't you also replace the code that does this verification?

That is exactly how games are cracked, as I understand.

[antoinealb → fooker]

No, because the code doing this verification is also checked by the loader, which is checked by the secure boot module. The secure boot module provides the trust root.