4 ms·

I'm a little confused about something: in a locked-down kernel, what would prevent the user from just replacing the kernel image and rebooting? Would the kernel

I'm a little confused about something: in a locked-down kernel, what would prevent the user from just replacing the kernel image and rebooting? Would the kernel lock down the image? EDIT: Sorry for the confusion, I mean lockdown without Secure Boot -- I thought Linus was saying they were independent things, so I was trying to see how lockdown could work independently of Secure Boot.

Karliss 9y ago
Secure Boot not allowing to boot your unsigned replacement image?
TheDong 9y ago
If secure-boot is enabled, the new image would need to be signed in order to be booted. If the user can sign an image with a trusted key, than sure, but it's assumed that an attacker does not have secureboot keys.
Jasper_ 9y ago
Andy suggests one mode of operation: a truly read-only boot filesystem that the kernel itself can't modify. And there is general agreement from all parties to add a kernel command line flag to support that use case. Otherwise, on a more general-purpose computer with a writable /boot/, some verified boot like secure boot is required to ensure that your chain of trust is established.
mjg59 9y ago
There's a few options: 1) Your kernel is in flash and your firmware won't update it unless it's signed. In that case the fact that there's no secure boot as such is irrelevant, because you can assert that the hardware is providing a root of trust anyway 2) Your firmware measures the kernel into something like a TPM and the TPM won't release a secret that's required to boot unless that measurement is correct. https://mjg59.dreamwidth.org/35742.html https://mjg59.dreamwidth.org/35742.html describes a couple of shortcomings in that approach and how you can get around them - if you do that appropriately, there's no risk 3) Your system has some other kind of verified boot implementation (such as ChromeOS) But otherwise yes, that's the point - defaulting lockdown to on while it's still easy for an attacker to replace the kernel may not be a great default, because it removes functionality without offering much additional security.

Karliss 9y ago

Secure Boot not allowing to boot your unsigned replacement image?

TheDong 9y ago

If secure-boot is enabled, the new image would need to be signed in order to be booted. If the user can sign an image with a trusted key, than sure, but it's assumed that an attacker does not have secureboot keys.

Jasper_ 9y ago

Andy suggests one mode of operation: a truly read-only boot filesystem that the kernel itself can't modify. And there is general agreement from all parties to add a kernel command line flag to support that use case. Otherwise, on a more general-purpose computer with a writable /boot/, some verified boot like secure boot is required to ensure that your chain of trust is established.

mjg59 9y ago

There's a few options: 1) Your kernel is in flash and your firmware won't update it unless it's signed. In that case the fact that there's no secure boot as such is irrelevant, because you can assert that the hardware is providing a root of trust anyway 2) Your firmware measures the kernel into something like a TPM and the TPM won't release a secret that's required to boot unless that measurement is correct. https://mjg59.dreamwidth.org/35742.html https://mjg59.dreamwidth.org/35742.html describes a couple of shortcomings in that approach and how you can get around them - if you do that appropriately, there's no risk 3) Your system has some other kind of verified boot implementation (such as ChromeOS) But otherwise yes, that's the point - defaulting lockdown to on while it's still easy for an attacker to replace the kernel may not be a great default, because it removes functionality without offering much additional security.