On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote: > On 15-10-20 08:48:20, Mimi Zohar wrote: > > On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote: > > > > > > This is all we've been using the blacklist keyring so far. By semantics > > > it > > > is system-wide keyring so maybe the commit message should be changed. > > > Nothing prevents others from using it. > > > > > > The problem is that an IMA option enables the creation of this keyring, > > > which makes it IMA specific for the moment. If it is decided that the > > > blacklist keyring should be detached from it's IMA bonds then i guess two > > > things should happen: 1) broader discussion (perhaps involving David); > > > and > > > 2) modifying the patches; > > > > > > BTW, same applies for the MOK keyring. If you want these to be more > > > generally used i assume a discussion is in order. > > > > I understand these keyrings could be useful for the more general case, but > > lets first discuss IMA. I'm trying to understand why the blacklist is tied > > so > > closely to just the .ima_mok keyring in the Kconfig. Is the need for > > blacklisting keys any less if the key is on the .ima keyring vs. the > > .ima_mok > > keyring? > > 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? Mimi -- 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
