7:35 p.m.
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!
7:42 p.m.
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
8:06 a.m.
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!
8:19 a.m.
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
8:27 a.m.
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!
7:11 a.m.
> 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?)?
4198
days inactive
4200
days old
kernel@lists.fedoraproject.org
5 comments
2 participants
participants (2)
-
Josh Boyer -
Mr Dash Four