5 ms·

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

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?

hobarrera 9y ago
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 9y ago
  In fact OpenBSD already generates a checksum for each kernel.
Ded7xSEoPKYNsDd 9y ago
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.
clarry 9y ago
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 9y ago
  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_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... https://wiki.gentoo.org/wiki/Signed_kernel_module_support https://wiki.gentoo.org/wiki/Signed_kernel_module_support
  - snuxoll 9y ago
    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 9y ago
      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 9y ago
        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. :)
lambdadmitry 9y ago
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 https://news.ycombinator.com/item?id=14711983
- fooker 9y ago
  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 9y ago
    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.

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?

hobarrera 9y ago

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 9y ago
In fact OpenBSD already generates a checksum for each kernel.

Ded7xSEoPKYNsDd 9y ago

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.

clarry 9y ago

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 9y ago
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_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterp... https://wiki.gentoo.org/wiki/Signed_kernel_module_support https://wiki.gentoo.org/wiki/Signed_kernel_module_support
- snuxoll 9y ago
  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 9y ago
    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 9y ago
      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. :)

lambdadmitry 9y ago

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 https://news.ycombinator.com/item?id=14711983

fooker 9y ago
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 9y ago
  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.