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-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
