Re: Secureboot: how to use MOK

[Florian Weimer]

* Steve Langasek:

>> and this is the reason we have to require all modules to be signed by
>> default.
>
> Enforcement of kernel module signatures is part of what's called the
> "lockdown" featureset.  It is optional, and not a requirement from
> the UEFI spec,

The requirement is in the Microsoft signing policy (or the document
that comes closest to such a policy):

|  b. Developers might assume that secure boot security requirements
|  have been satisfied when their initial boot is complete. However,
|  if a secure boot system permits launch of another operating system
|  instance after execution of unauthenticated code, the security
|  guarantee of secure boot is compromised. If this vulnerability is
|  exploited, the submission might be revoked.



Admittedly, that part isn't entirely clear. I think most vendors have
an escape hatch to load unsigned kernel modules even in secure boot
mode, without a reboot or physical presence check.

Re: Secureboot: how to use MOK

[Steve Langasek]

On Thu, Nov 07, 2019 at 03:04:16AM +0100, Ansgar wrote:
> Steve Langasek writes:
> > On Sun, Oct 27, 2019 at 10:45:49AM +0100, Florian Weimer wrote:
> >> * Thomas Goirand:
> >> I don't think secure boot provides any benefit at all if you store the
> >> kernel module signing key on the same machine.

> > Generate the MOK certificate with EKU 1.3.6.1.4.1.2312.16.1.2.  This
> > indicates that the key should only be trusted for kernel modules, not for
> > kernels or other EFI applications (bootloaders etc).  The value is honored
> > by shim, grub (via shim), and the kernel (but not by the firmware - but the
> > firmware itself doesn't trust the MOK anyway, so this doesn't matter).

> > This does not eliminate all attacks that involve getting access to the
> > private key on the machine; but it does prevent the presence of MOK + DKMS
> > being used to attack the firmware.

> I thought the Linux kernel did not call `ExitBootServices()`

I don't know why you have the impression that it doesn't.  This is basically
the first thing the EFI entry point does, after taking care of certain EFI
fixups.

> and this is the reason we have to require all modules to be signed by
> default.

Enforcement of kernel module signatures is part of what's called the
"lockdown" featureset.  It is optional, and not a requirement from the UEFI
spec, but there are various reasons why one might want this added security
and so it's quite reasonable to key its enablement on whether or not your
system has booted with SecureBoot enabled (if SecureBoot is NOT enabled,
then there's no point in enforcing module signatures since your pre-boot
execution environment is not secure anyway and an attacker could just
replace your kernel, or trick your kernel into trusting other keys for
signatures.)

> (Or even if it did, this applies to all modules loaded before.) So the
> Linux kernel should be able to chainload anything, just like shim.

The kernel doesn't load any modules before calling ExitBootServices.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Secureboot: how to use MOK

[Ansgar]

Steve Langasek writes:
> On Sun, Oct 27, 2019 at 10:45:49AM +0100, Florian Weimer wrote:
>> * Thomas Goirand:
>> I don't think secure boot provides any benefit at all if you store the
>> kernel module signing key on the same machine.
>
> Generate the MOK certificate with EKU 1.3.6.1.4.1.2312.16.1.2.  This
> indicates that the key should only be trusted for kernel modules, not for
> kernels or other EFI applications (bootloaders etc).  The value is honored
> by shim, grub (via shim), and the kernel (but not by the firmware - but the
> firmware itself doesn't trust the MOK anyway, so this doesn't matter).
>
> This does not eliminate all attacks that involve getting access to the
> private key on the machine; but it does prevent the presence of MOK + DKMS
> being used to attack the firmware.

I thought the Linux kernel did not call `ExitBootServices()` and this is
the reason we have to require all modules to be signed by default.  (Or
even if it did, this applies to all modules loaded before.)  So the
Linux kernel should be able to chainload anything, just like shim.

So why does this prevent attacks on the firmware?  It shouldn't matter
if you can sign the kernel or any module run in the same context as the
kernel.

Ansgar

Re: Secureboot: how to use MOK

[Steve Langasek]

On Sun, Oct 27, 2019 at 10:45:49AM +0100, Florian Weimer wrote:
> * Thomas Goirand:

> > I've setup my new laptop with secureboot, and now, I can't use the DKMS
> > modules from Virtualbox, as they aren't signed. I've been told by Sledge
> > that I should use MOK to do that, and that DKMS packages are supposed to
> > have all in them to support MOK.

> I don't think secure boot provides any benefit at all if you store the
> kernel module signing key on the same machine.

Generate the MOK certificate with EKU 1.3.6.1.4.1.2312.16.1.2.  This
indicates that the key should only be trusted for kernel modules, not for
kernels or other EFI applications (bootloaders etc).  The value is honored
by shim, grub (via shim), and the kernel (but not by the firmware - but the
firmware itself doesn't trust the MOK anyway, so this doesn't matter).

This does not eliminate all attacks that involve getting access to the
private key on the machine; but it does prevent the presence of MOK + DKMS
being used to attack the firmware.

We do this by default in Ubuntu with dkms.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Secureboot: how to use MOK

[Thomas Goirand]

On 10/27/19 10:45 AM, Florian Weimer wrote:
> * Thomas Goirand:
> 
>> I've setup my new laptop with secureboot, and now, I can't use the DKMS
>> modules from Virtualbox, as they aren't signed. I've been told by Sledge
>> that I should use MOK to do that, and that DKMS packages are supposed to
>> have all in them to support MOK.
> 
> I don't think secure boot provides any benefit at all if you store the
> kernel module signing key on the same machine.

Probably, though if my HDD is encrypted, it still provides some higher
level of security.

Thomas Goirand (zigo)

Re: Secureboot: how to use MOK

[Florian Weimer]

* Thomas Goirand:

> I've setup my new laptop with secureboot, and now, I can't use the DKMS
> modules from Virtualbox, as they aren't signed. I've been told by Sledge
> that I should use MOK to do that, and that DKMS packages are supposed to
> have all in them to support MOK.

I don't think secure boot provides any benefit at all if you store the
kernel module signing key on the same machine.

Re: Secureboot: how to use MOK

[Thomas Goirand]

On 10/25/19 4:52 PM, Thomas Goirand wrote:
> Hi,
> 
> I've setup my new laptop with secureboot, and now, I can't use the DKMS
> modules from Virtualbox, as they aren't signed. I've been told by Sledge
> that I should use MOK to do that, and that DKMS packages are supposed to
> have all in them to support MOK.
> 
> So my question is:
> - where may I find a doc for MOK, as a user. And by that, I don't mean
> the official MOK doc, where it explains how to install MOK from scratch
> (which isn't useful to me...), but more, how can I just enrol a new key
> and sign my kernel modules with them.
> - the above probably belongs to debian-users, though, not this one. Is
> there a DKMS package out there that supports MOK the correct way, so I
> could cheat on it, and contribute this to the Virtualbox package?
> 
> Cheers,
> 
> Thomas Goirand (zigo)

Someone sent me a quick howto (I'm not sure why he did that in private).
I've written that on the wiki, for everyone to use:

https://wiki.debian.org/SecureBoot#Enroling_a_new_key

In fact, it's rather easy.

Now the question remains: how to do all of this automatically in a DKMS
module?

Cheers,

Thomas Goirand (zigo)