On 28/05/15 17:45, Josh Boyer wrote:
On Thu, May 28, 2015 at 11:26 AM, David Sommerseth
> 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
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 ...
It is worth noting that Fedora does not allow packages other than
kernel to ship kernel modules.
Oh, I was not aware of that. But compiling a kernel module "on-the-fly"
is acceptable for Fedora?
> 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
> 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"
> 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