On Wed, 2015-05-20 at 00:19 +0200, Luis R. Rodriguez wrote: > On Tue, May 19, 2015 at 05:48:37PM -0400, Mimi Zohar wrote: > > On Tue, 2015-05-19 at 22:02 +0200, Luis R. Rodriguez wrote: > > > David Howells has posted v4 of his series of supporting PKCS#7 for module > > > signing. I'm in my v3 series now on RFCs for firmware PKCS#7 support, and > > > after > > > some review and patch shuffling I think this is ready for patch form. My > > > own > > > series however depend on quite a bit of other pending changes, one series > > > which > > > will go through Rusty's tree, another series of fixes on firmware_class > > > which > > > should go through Greg's tree. I'll wait until all this and David's own > > > patches > > > get merged before posting firmware PKCS#7 support. Before all this though > > > in > > > preparation for fw signing one thing we should start to talk about more > > > broadly > > > however is how linux-firmware binary file signing would work in practice > > > and > > > what we need, and make sure folks are OK with all this. > > > > Commit 13752fe "security: introduce kernel_fw_from_file hook" introduced > > a new security hook. (IMA is on this hook as well.) Have you > > considered using this hook? > > Yes, the same hook is used here. > > > Are there other places that this hook would need to be called? > > Nope, it'd be called. Folks who do not want to use key signing stuff can use > their own preferred LSM hook just as module signing has the kernel module > signing infrastructure but also module LSM hooks. It'd be similar here for > firmware.
When the kernel module signing signature verification was upstreamed, Rusty was not aware of IMA-appraisal - https://lkml.org/lkml/2013/1/22/20 In this case, not only is there a security hook, but the IMA hook exists as well. To appraise firmware, add a line to the IMA policy containing "appraise func=FIRMWARE_CHECK". Similarly, to add a measurement to the measurement list, add a line to the IMA policy containing "measure func=FIRMWAE_CHECK". > Now that we have LSM hooks stacked on the way perhaps this is more in line > with > what Andy has envisioned for alternatives for module signature verification. > But then again since an LSM hook already exists for both modules and firmware > perhaps this is sufficient for what Andy envisions? That is if folks do not > want > this signing thing just disable it and add use your preferred LSM module of > choice? > > Now granted -- if we envision this module signing infrastructure as an LSM > hook > in and of itself perhaps we should LSM'ify it. Its not right now. > > > > I think we need one change here, we'd need to ensure that such key could > > > only > > > be used for vetting firmware files, not modules loaded. The > > > firmware_class > > > could for instance still use all the keys in system_trusted_keyring, which > > > would include the UEFI key db, but it does not seems reasonable to expect > > > keys > > > used for fw signing to also go into system_trusted_keyring to also be > > > used for > > > module signing. > > > > I agree totally! For this reason, IMA defined a separate trusted > > keyring to be used for verifying file signatures. > > OK I'll add that to my TODO list here. You'll probably want to create a new trusted firmware keyring. By trusted, only signed keys by a key on the system_keyring can be added to the.ima keyring. Using the "ca_keys" boot command line option a specific key on the system keyring can be specified. Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/