3 ms·

Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signe

by MertsA 9y ago

Checking at install time is effectively useless. The whole point of running signed code is that you can't just load some rootkit. Secure Boot only loads a signed bootloader which only loads a signed kernel which only loads signed kernel modules. You can't do what you're suggesting without fundamentally breaking this chain of trust. What's to stop a rootkit from just spoofing that it was installed months ago?

wtallis 9y ago
> What's to stop a rootkit from just spoofing that it was installed months ago? The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.
- MertsA 9y ago
  The whole point of signing everything from the bootloader on down is to make sure that even ring 0 control over the computer can't persist through a reboot. Allowing signatures to work the way it was suggested would break any hope of something like Secure Boot ever working. As it is you're already trusting timestamping certificates to effectively live forever.
dannyw 9y ago
The signed kernel keeps track of when it first has seen a certificate. That is signed by a kernel, so a rootkit can’t spoof unless the system is already compromised.
- MertsA 9y ago
  Even the kernel can't modify its own code and persist through a reboot. The kernel only loads signed code that isn't malicious, the bootloader only loads signed kernels that aren't malicious and don't allow you to run malicious code as ring 0, and the BIOS only loads signed bootloaders, etc. There's a root of trust from the hardware on down that makes sure that you cannot run unsigned code as ring 0 and if there's a compromise it can't persist through a reboot. Allowing the kernel to mark certain modules as "signed" like you're suggesting would allow a rootkit to install itself via some exploit. This would render moot the whole point of Secure Boot in the first place.

by MertsA 9y ago

wtallis 9y ago

> What's to stop a rootkit from just spoofing that it was installed months ago? The fact that if a rootkit is in a position to performing that spoofing, it doesn't need to, because it already has the power to make arbitrary modifications to the system image.

MertsA 9y ago
The whole point of signing everything from the bootloader on down is to make sure that even ring 0 control over the computer can't persist through a reboot. Allowing signatures to work the way it was suggested would break any hope of something like Secure Boot ever working. As it is you're already trusting timestamping certificates to effectively live forever.

dannyw 9y ago

The signed kernel keeps track of when it first has seen a certificate. That is signed by a kernel, so a rootkit can’t spoof unless the system is already compromised.

MertsA 9y ago
Even the kernel can't modify its own code and persist through a reboot. The kernel only loads signed code that isn't malicious, the bootloader only loads signed kernels that aren't malicious and don't allow you to run malicious code as ring 0, and the BIOS only loads signed bootloaders, etc. There's a root of trust from the hardware on down that makes sure that you cannot run unsigned code as ring 0 and if there's a compromise it can't persist through a reboot. Allowing the kernel to mark certain modules as "signed" like you're suggesting would allow a rootkit to install itself via some exploit. This would render moot the whole point of Secure Boot in the first place.