Bug#931440: wireguard module needs signing to work with secureboot

[hello i'm a lizard]

Package: wireguard
Version: 0.0.20190702-1
Severity: important

The wireguard kernel module installed by wireguard-dkms doesn't appear to be
signed and is therefore unusable on a secureboot system (without me figuring
out how the whole mok key thing works and manually signing it myself). Since
debian is building and packaging a signed kernel, could you also do this for
this module?

error messages:

[ 18.375387] Lockdown: Loading of unsigned modules is restricted; see
https://wiki.debian.org/SecureBoot

# modprobe wireguard
modprobe: ERROR: could not insert 'wireguard': Required key not available

Thanks!



-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireguard depends on:
ii wireguard-dkms 0.0.20190702-1
ii wireguard-tools 0.0.20190702-1

wireguard recommends no packages.

wireguard suggests no packages.

-- no debconf information

[Daniel Kahn Gillmor]

Control: retitle 931440 dkms-built modules are not signed, do not work with secureboot
Control: reassign 931440 dkms
Control: affects 931440 + wireguard-dkms src:wireguard
Control: tags 931440 + help

Hi Lizard--

On Fri 2019-07-05 01:32:58 +0100, hello i'm a lizard wrote:
> The wireguard kernel module installed by wireguard-dkms doesn't appear to be
> signed and is therefore unusable on a secureboot system (without me figuring
> out how the whole mok key thing works and manually signing it myself). Since
> debian is building and packaging a signed kernel, could you also do this for
> this module?

Debian doesn't ship binary modules for wireguard, so the modules that
you are (rightly) concerned about are built via dkms.

I agree with the problem that you've described, but i think the same
problem is true for all modules built via dkms, so i'm reassigning this
bug report to dkms itself, as i think that's where the issue probably
needs to be addressed.

Unfortunately, i'm not entirely sure how to address it -- how should a
secureboot system deal with these keys safely while still keeping a
rogue administrator from being able to install arbitrary modules?

I'd appreciate any guidance from secureboot experts on the intersection
of secureboot and dkms here.

Regards,

--dkg

[Siddh Raman Pant]

Hello,

dkms v3 has automatic signing of modules, and v3.0.7 has it working for debian.

For some reason it isn't signing while using apt, but is signing when I manually
remove and add the modules. I infer signing is being done when it is shown in
the output, which was not the case when I installed nvidia-driver.

Thanks,
Siddh

[Siddh Raman Pant]

On Fri, 7 Oct 2022 11:41:31 +0530, I wrote:
> For some reason it isn't signing while using apt, but is signing when I manually
> remove and add the modules. I infer signing is being done when it is shown in
> the output, which was not the case when I installed nvidia-driver.

So it was due to MOK key locations in DKMS config not being set to distro defaults.
That's all what is needed if your keys aren't protected by a passphrase. Otherwise,
we can use the sign_helper.sh which was used to in sign_tool config prior to v3 in
the sign_file config.

If anyone stumbles upon this thread, my config can be found on:
https://gist.github.com/siddhpant/19c07b07d912811f5a4b2893ca706c99

Thanks,
Siddh