On 15-10-20 10:13:34, Mimi Zohar wrote: > On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote: > > > > The code does not ties these keyrings around IMA. The way i've done it, > > they are actually system wide keyrings and any other subsystem may use them. > > > > Since there was no general discussion (hence agreement) that the Linux > > kernel need these keyrings i've put them within the IMA config options. > > For > > now only IMA users interested in creating CA hierarchy should use them. > > > > > Basically, I'm trying to better understand the use case scenario. > > > > To build CA hierarchy we basically need two things: > > > > - system wide keyring writable at runtime, i.e. .ima_mok; > > - system wide blacklist keyring writable at runtime, i.e. .blacklist; > > > > .system is read-only and populated at kernel build time. During the > > lifetime (as in runtime) of the machine we need to dynamically add tenant's > > certificates and IMA keys. Without .ima_mok this can not be done easily > > because most of tenant's certificates are not available at krenel build > > time. Most of these have one year of validity and must be replaced, while > > the router's uptime is typically much longer. > > > > While the current kernel key code handles CA expiration it does not handle > > blacklisted certificates or keys. The patch add checks to this keyring so > > any CA that has been compromised can't harm the system. > > > > .ima_mok and .blacklist are IMA-enabled features for the moment not by > > semantics, but by policy. I do think they should become system wide one > > day > > and there are good reasons to do so. > > All very good! As we discussed, this can and should be upstreamed initially > for IMA. > > My question, however, has more to do with the last paragraph of the patch > description which says, "IMA blacklist keyring contains all revoked IMA keys. > > It is consulted before any other keyring. If the search is successful the > requested operation is rejected and error is returned to the caller." > > If the IMA blacklist keyring is for ALL IMA keys, those on the the original > .ima keyring and those on the .ima_mok keyring, then why is the Kconfig tied > to the .ima_mok keyring? Does it make sense to have a blacklist keyring > without the .ima_mok keyring? Should there be a separate Kconfig blacklist > keyring option?
Since having a proper CA hierarchy means access to both keyrings i never thought about separating them. The blacklist keyring should be functional without it's counterpart so yes, i think it should be possible to have option for each of them, i.e. one for .ima_mok and one for .blacklist. I am OK with finer granularity of the IMA options. I wonder, though, whether the casual user will grasp the idea. In short - do you want me to add separate options for the two keyrings in Kconfig? Petko -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html