Secure boot and packaging third-party kernel modules

[David Sommerseth]

On 28/05/15 17:45, Josh Boyer wrote:
> 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?

Duh!  I'm so into this I forget to add better project info ...

<https://sites.google.com/site/linuxvtl2/>


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

Oh, I was not aware of that.  But compiling a kernel module "on-the-fly"
is acceptable for Fedora?

[...snip...]

>> 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.

I generally prefer the most strict approaches, I don't want users to
feel that a package I introduce may lower the overall security in any
way - unless that is the only working alternative.  I do see it doesn't
makes it "easy" to implement, but that's how it is.

>> 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.

Thanks!


--
kind regards,

David Sommerseth