Kernel not enforcing module signatures under SecureBoot

[Kees Cook]

$ sudo mokutil --sbstate
SecureBoot enabled
$ cat /proc/sys/kernel/moksbstate_disabled
0
$ sudo insmod ./hello.ko
$ echo $?
0
$ dmesg | grep Hello
[00112.530866] Hello, world!
$ strings /lib/modules/$(uname -r)/kernel/lib/test_module.ko | grep signature
~Module signature appended~
$ strings hello.ko | grep signature
$ uname -r
4.8.0-34-generic

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1658255

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Tim Gardner (timg-tpi)]

Kees - what is the result of 'cat /proc/sys/kernel/secure_boot' ?

[Kees Cook (kees)]

$ cat /proc/sys/kernel/secure_boot
0

That seems weird. Everything else thinks it's enabled. What sets this one (and what does it represent)?

[Kees Cook (kees)]

(Hm, dmesg WARN on IOMMU seems to think I need 910170442944e1f8674fd5ddbeeb8ccd1877ea98, but that's unrelated...)

[Kees Cook (kees)]

the proc handler does:
        secure_boot_enabled = efi_enabled(EFI_SECURE_BOOT);
this feature flag is set at boot:
#ifdef CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE
        if (boot_params.secure_boot == EFI_SECURE_BOOT) {
                set_bit(EFI_SECURE_BOOT, &efi.flags);
                enforce_signed_modules();
                pr_info("Secure boot enabled\n");
        }

And since I don't see the pr_info, nor the flag, nor the module enforcement, the boot_params is probably missing?

[Kees Cook (kees)]

Oh, and that's not set up by the bootloader, it's in arch/x86/boot/compressed/eboot.c:

        boot_params->secure_boot = get_secure_boot();

[Kees Cook (kees)]

And that must be doing something wrong, since:

sudo efivar -p -n $(efivar --list | grep SecureBoot)

shows "1"

[Kees Cook (kees)]

And it looks like this is specific to the 4.8 kernel. 4.4 thinks secure boot is enabled.

[Steve Beattie (sbeattie)]

I have reproduced this and can confirm it only affects 4.8 kernels. I have a Ubuntu 16.04 system with secure boot enabled, and the 4.4 kernels were enforcing it. Installing and rebooting into the linux-image-generic-hwe-edge kernel (4.8.0-34.36~16.04.1-generic) and everything before the kernel thinks secure boot is enabled, but the kernel does not and freely loads unsigned modules.

$ cat /proc/version_signature
Ubuntu 4.4.0-59.80-generic 4.4.35
$ mokutil --sb-state
SecureBoot enabled
$ sysctl kernel.secure_boot
kernel.secure_boot = 1

$ cat /proc/version_signature
Ubuntu 4.8.0-34.36~16.04.1-generic 4.8.11
$ mokutil --sb-state
SecureBoot enabled
$ sysctl kernel.secure_boot
kernel.secure_boot = 0

[Steve Beattie (sbeattie)]

Bah, was missing the linux-signed-generic-hwe-16.04-edge package. Once that was in place, secure boot enforcement works correctly. Not sure if that's the cause of Kees' issue as well.

That said, making it more discoverable that (a) secure boot is not being enforced by the kernel, (b) why it's not being enforced, and (c) shouldn't a boot stack that's enforcing secure boot not permit an unsigned kernel to boot?

[Steve Beattie (sbeattie)]

Also, is there a reason there isn't at least recommends on the corresponding -signed packages for the kernel, to try to avoid this situation? (I realize adding a hard depends would make building/installing test kernels more difficult.)

[Kees Cook (kees)]

... why aren't all the kernels just signed? Why does this need to be a separate package at all?

I can confirm installing the -signed package fixes it for me. Where in the kernel source does this signature effect the output of /proc/sys/kernel/secure_boot, though? I can't find that...

[Tim Gardner (timg-tpi)]

Kees - there are archive shenanigans involved in getting a signed kernel binary, hence the separate package.

Steve - I'm not sure about the rationale for grub booting unsigned kernels. The foundations team might be able to explain it.

[Andy Whitcroft (apw)]

This bug was nominated against a series that is no longer supported, ie yakkety. The bug task representing the yakkety nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.