On 28/05/15 17:45, Josh Boyer wrote: > On Thu, May 28, 2015 at 11:26 AM, David Sommerseth <dav...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
