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. > 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. > 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. But really the best solution here is to get the mhvtl kernel module upstream. -- David Smith dsmith@xxxxxxxxxx Red Hat http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
