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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
