Secure boot and packaging third-party kernel modules

[Josh Boyer]

On Thu, May 28, 2015 at 11:26 AM, David Sommerseth <davids at redhat.com> wrote:
>
> Hi,
>
> I've started poking into packaging the mhvtl project for Fedora and
> EPEL.  This package also contains a kernel module, which normally works
> fine - until you hit Secure Boot.
>
> So I was wondering how to handle this the best way.  AFAIK, there are
> currently no plans to get the mhvtl.ko kernel module into the upstream
> kernel.

Where can I read more information on this project, and why that might be?

It is worth noting that Fedora does not allow packages other than the
kernel to ship kernel modules.

> Some packages (VirtualBox, IIRC) can compile the kernel module
> on-the-fly if it is missing during boot.  That's an easy thing to
> implement.  But for secure boot, things gets complicated as the kernel
> module needs to be signed.
>
> I've played with mokutil and the sign-file script which is in
> kernel-devel, based on this article [1].  This all works fine.  I could
> easily install my own key, compile the mhvtl.ko module and sign it.  And
> then it was possible to load the module.
>
> [1]
> <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-signing-kernel-modules-for-secure-boot.html>
>
> It's also important to remember that kernels do get updated.  So when a
> new kernel is installed, it is (to my knowledge) required to recompile
> the module.  If I'm mistaken, please educate me!

You are correct here.

> My current idea to solve this is to:
>
> * Have a "preparation" script which the admin is required to run
>   on a new system.  This scripts generates the needed key material and
>   runs mokutil which installs the key.  It will then provide enough
>   information so that the admin can reboot the system and get the MOK
>   key installed.
>
> * Have a unit file which runs a ExecStartPre= script.  This script
>   will check if the key material exists.  If it does, it will check
>   if the mhvtl.ko module for the currently running kernel exists.
>   If the module is missing, it will compile it, sign it and load it.
>   Failures along the way will cause the unit file to fail all together.
>   When the ExecStartPre= script has completed successfully, it will
>   start the needed processes it normally would do.
>
>
> Any thoughts or comments to this approach?  Anyone got a better idea?

The above approach seems mostly sane.  It does seem like a lot of
hassle, but it's what is required if you want to leave SB validation
enabled.  Otherwise, you could have your preparation script disable
mokutil validation at the risk of no longer leveraging the SB
protections for grub, the kernel, or the kernel modules.  Shim is
still validated by UEFI itself as SB is still enabled in the firmware.

> Yes, I do know it is not good to have the keying material for the
> signing too easily available.  So I'm also keen to hear ideas how to
> protect the key better.  With that said, I'm planning on only providing
> access to the key file to the root user only.  And I'll look into if I
> can restrict the accesss even further with some SELinux rules (so only
> the ExecStartPre= script can access it together with the "preparation"
> script.
>
> Another thought ... Are there other packages who could benefit of such a
> solution if it was made more generic?  I'm willing to investigate into
> this too, if there are more users out there ... Or if someone has
> already done that - no need to reinvent the wheel!

I'm not aware of any.  The one place that might be worth looking is
rpmfusion, as I would expect they need to do something similar for the
kernel module packages they build if they care about running with SB
enabled.

josh