I seem to remember in one of the early 3.6-RC kernel versions there were provisions put in the .spec file to sign all kernel code and its modules using the above facility. I can't find this in the 3.6.1 or 3.6.2 versions of the kernel currently in the Fedora srpm files. Has this been dropped?
On a related issue - if, for some reason, I am unable to deploy UEFI (disabled, so that Windows 8 won't prevent me from installing/using/booting up Linux) can I still sign the kernel and its modules and enforce these checks at startup with the bootloader (grub2)? Would that be possible? Thanks!
On Fri, Oct 19, 2012 at 01:35:25AM +0100, Mr Dash Four wrote:
I seem to remember in one of the early 3.6-RC kernel versions there were provisions put in the .spec file to sign all kernel code and its modules using the above facility. I can't find this in the 3.6.1 or 3.6.2 versions of the kernel currently in the Fedora srpm files. Has this been dropped?
No. It's only present in F18 and rawhide, but it's still there.
On a related issue - if, for some reason, I am unable to deploy UEFI (disabled, so that Windows 8 won't prevent me from installing/using/booting up Linux) can I still sign the kernel and its modules and enforce these checks at startup with the bootloader (grub2)? Would that be possible? Thanks!
I'm guessing you meant "Secure Boot" and not "UEFI". If so, the answer is sort of. grub2 won't check the kernel, but it will still be signed if it's a 64-bit F18 or newer release kernel. The modules will all be signed regardless as that's done with a different key generated at kernel build time. There's a kernel parameter you can enable to force the kernel into a "secure boot" mode.
Without the secure firmware, I'm not entirely sure why you'd want to do that though. It won't prevent bootloader based attacks. If you just want signed modules, there's a different kernel parameter you can pass to enforce signed modules.
josh
No. It's only present in F18 and rawhide, but it's still there.
OK, thanks.
I'm guessing you meant "Secure Boot" and not "UEFI".
Yeah, sorry, that's what I meant.
If so, the answer is sort of. grub2 won't check the kernel, but it will still be signed if it's a 64-bit F18 or newer release kernel.
Would that be possible - for the kernel to be checked - or is that only allowed from Secure Boot?
The modules will all be signed regardless as that's done with a different key generated at kernel build time.
The whole point of me asking this is, because I wish to use my own key (not Fedora's and certainly not M$) and when I build the kernel - from source - I wish this to be signed and later enforced, if possible.
There's a kernel parameter you can enable to force the kernel into a "secure boot" mode.
I presume I could find the appropriate parameter documented in the kernel docs directory, right?
Without the secure firmware, I'm not entirely sure why you'd want to do that though. It won't prevent bootloader based attacks.
I am aware of that, but at least it would prevent loading rogue modules, which either haven't been signed or have been altered.
If you just want signed modules, there's a different kernel parameter you can pass to enforce signed modules.
Ideally, I'd like to protect the kernel as well, but if that's not possible then just the modules will do.
In an ideal world, I would like to have the option to boot my UEFI in "Setup" mode so that I could register my own platform key, which could then be used to register all other "trusted" keys (including the M$ one - if I choose to trust it) and then enable UEFI to boot in as normal, enforcing bootloader, kernel as well as kernel module signatures.
In reality though, I am finding it difficult to find a hardware manufacturer who distributes motherboards with that option enabled (UEFI in "Setup" mode) - the most I could get, and it still seems a rarity these days, is to have a separate key registered, alongside the already existing one (which, in 99% of the cases is from M$).
That, while acceptable somewhat, forces me to trust the master key, which I am not willing to do - it should be up to me as owner of my own hardware (My PC!) to choose what to trust and what not to. Apologies for this rant, but it had to be said!
On Fri, Oct 19, 2012 at 02:06:16PM +0100, Mr Dash Four wrote:
If so, the answer is sort of. grub2 won't check the kernel, but it will still be signed if it's a 64-bit F18 or newer release kernel.
Would that be possible - for the kernel to be checked - or is that only allowed from Secure Boot?
You'd have to write some code for both grub2 and shim. Grub2 doesn't actually do the authentication itself, it calls back to shim to do that. And shim is looking in two databases for certs/hashes.
You'd probably need to rebuild shim with your personal key embedded, and modified to always verify. Then you'd need to modify grub2 to always call shim to do verification and install that. I honestly have no idea how difficult that would be.
The modules will all be signed regardless as that's done with a different key generated at kernel build time.
The whole point of me asking this is, because I wish to use my own key (not Fedora's and certainly not M$) and when I build the kernel
- from source - I wish this to be signed and later enforced, if
possible.
There's a kernel parameter you can enable to force the kernel into a "secure boot" mode.
I presume I could find the appropriate parameter documented in the kernel docs directory, right?
It's carried in the patchset and put in Documentation/kernel-parameters.txt. It's called "secureboot_enable=".
Without the secure firmware, I'm not entirely sure why you'd want to do that though. It won't prevent bootloader based attacks.
I am aware of that, but at least it would prevent loading rogue modules, which either haven't been signed or have been altered.
The kernel doesn't need to be signed for that as I said.
If you just want signed modules, there's a different kernel parameter you can pass to enforce signed modules.
Ideally, I'd like to protect the kernel as well, but if that's not possible then just the modules will do.
In an ideal world, I would like to have the option to boot my UEFI in "Setup" mode so that I could register my own platform key, which could then be used to register all other "trusted" keys (including the M$ one - if I choose to trust it) and then enable UEFI to boot in as normal, enforcing bootloader, kernel as well as kernel module signatures.
In reality though, I am finding it difficult to find a hardware manufacturer who distributes motherboards with that option enabled (UEFI in "Setup" mode) - the most I could get, and it still seems a rarity these days, is to have a separate key registered, alongside the already existing one (which, in 99% of the cases is from M$).
You should be able to disable Secure Boot in the firmware, and reboot back into setup mode. It should allow you to delete all the existing keys at that point. Though you'd actually need to have a machine that has Secure Boot implemented in the first place.
That, while acceptable somewhat, forces me to trust the master key, which I am not willing to do - it should be up to me as owner of my own hardware (My PC!) to choose what to trust and what not to. Apologies for this rant, but it had to be said!
You can. In order to be specification compliant, the machine needs to allow you to disable Secure Boot. Once that's done, it'll enter setup mode. Once in that mode, I believe there are even some open source tools that will help you enroll keys, etc.
josh
You'd have to write some code for both grub2 and shim. Grub2 doesn't actually do the authentication itself, it calls back to shim to do that. And shim is looking in two databases for certs/hashes.
You'd probably need to rebuild shim with your personal key embedded, and modified to always verify. Then you'd need to modify grub2 to always call shim to do verification and install that. I honestly have no idea how difficult that would be.
Looks complicated - I'll keep that option in mind as "plan B" if I get stuck and my "plan A" is not feasible!
It's carried in the patchset and put in Documentation/kernel-parameters.txt. It's called "secureboot_enable=".
Brilliant, thanks!
You should be able to disable Secure Boot in the firmware, and reboot back into setup mode. It should allow you to delete all the existing keys at that point. Though you'd actually need to have a machine that has Secure Boot implemented in the first place.
Aha! I wasn't aware of that (it tells me I could disable it, but I wasn't aware that I could delete all the keys... nice!).
You can. In order to be specification compliant, the machine needs to allow you to disable Secure Boot.
That is indeed the case!
Once that's done, it'll enter setup mode. Once in that mode, I believe there are even some open source tools that will help you enroll keys, etc.
I'll dig that up when I have more time. If I could manage to get that working the rest should fall into place quite easily and I won't need to mess around with shim/grub2. Thanks for that Josh, much appreciated!
Once that's done, it'll enter setup mode. Once in that mode, I believe there are even some open source tools that will help you enroll keys, etc.
I'll dig that up when I have more time. If I could manage to get that working the rest should fall into place quite easily and I won't need to mess around with shim/grub2. Thanks for that Josh, much appreciated!
OK, I've managed to sort out the above, but unfortunately, my issues now are with pesign itself.
I've submitted 4 bug reports with bugzilla yesterday, but even if I work around these I am still experiencing problems and can't get pesign to work properly. I am not sure whether this is the right place to post my pesign problems/woes or whether I should contact Peter Jones directly (is he on this ML?)?
kernel@lists.fedoraproject.org
-
Josh Boyer -
Mr Dash Four