See http://www.infradead.org/rpr.html > Luis R. Rodriguez <mcgrof@xxxxxxxx> wrote: > >> "PKCS#7: Add an optional authenticated attribute to hold firmware name" >> https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fwsign-pkcs7&id=1448377a369993f864915743cfb34772e730213good >> >> 1.3.6.1.4.1.2312.16 Linux kernel >> 1.3.6.1.4.1.2312.16.2 - PKCS#7/CMS SignerInfo attribute types >> 1.3.6.1.4.1.2312.16.2.1 - firmwareName >> >> I take it you are referring to this? > > Yes. > >> If we follow this model we'd then need something like: >> >> 1.3.6.1.4.1.2312.16.2.2 - seLinuxPolicyName >> >> That should mean each OID that has different file names would need to be >> explicit about and have a similar entry on the registry. I find that >> pretty >> redundant and would like to avoid that if possible. > > firmwareName is easy for people to understand - it's the name the kernel > asks > for and the filename of the blob. seLinuxPolicyName is, I think, a lot > more > tricky since a lot of people don't use SELinux, and most that do don't > understand it (most people that use it aren't even really aware of it). > > If you can use the firmwareName as the SELinux/LSM key, I would suggest > doing > so - even if you dress it up as a path (/lib/firmware/<firmwareName>). > > David > In conversation with Mimi last week she was very keen on the model where we load modules & firmware in such a fashion that the kernel has access to the original inode -- by passing in a f2f, or in the firmware case by doing the rd lookup directly. So surely you have all the SELinux labelling you need? -- dwmw2 -- 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
