Secure boot and packaging third-party kernel modules

[David Sommerseth]

On 28/05/15 23:03, David Smith wrote:
> On 05/28/2015 10:26 AM, David Sommerseth wrote:
> 
> ... stuff deleted ...
> 
>> Any thoughts or comments to this approach?  Anyone got a better idea?
> 
> Your process looks reasonable.

Thanks!

>> 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.
> 
> Systemtap has a similar problem. By definition, we compile kernel
> modules and still need to work on a secure boot system. To solve it, we
> automated the process you outlined above and added it to our existing
> "compile server" functionality. On a client machine you ask for a
> systemtap script to run, and behind the scenes the script gets shipped
> off to a compile server that has a matching kernel devel environment and
> matching MOKs. The signed module gets shipped back to the client system
> and run.
> 
> The advantage we have here is that if you have lots of client systems,
> none of them have the private MOK key installed on them - only the
> server has the private key(s). We only pass around public key fingerprints.

Right, that sounds like a good approach when you have a "compile
server".  For the mhvtl project, having a "compile server" isn't really
the right solution.

>> 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!
> 
> Systemtap's solution is probably pretty specific to ourselves, but the
> general idea (and perhaps some code) could certainly be borrowed.

Cool!  Thanks for the pointer!  I'll have a look at systemtap.

> But really the best solution here is to get the mhvtl kernel module
> upstream.

Agreed, but I'm not sure how keen upstream kernel developers are to
carry a driver for virtual tape devices.  I've asked mhvtl upstream if
that has been considered, but currently I'm not convinced that will
happen any time soon.


--
kind regards,

David Sommerseth