On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote: > On 15-10-19 14:20:48, Mimi Zohar wrote: > > On Fri, 2015-10-16 at 22:31 +0300, Petko Manolov wrote: > > > This option creates IMA MOK and blacklist keyrings. IMA MOK is an > > > intermediate keyring that sits between .system and .ima keyrings, > > > effectively forming a simple CA hierarchy. To successfully import a key > > > into .ima_mok it must be signed by a key which CA is in .system keyring. > > > On turn any key that needs to go in .ima keyring must be signed by CA in > > > either .system or .ima_mok keyrings. IMA MOK is empty at kernel boot. > > > > > > 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. > > > > Why is the blacklist so closely tied to the .ima_mok keyring? Is this > > keyring only used for blacklisting keys on the .ima_mok keyring or for > > blacklisting keys on the .ima keyring as well? > > 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? Basically, I'm trying to better understand the use case scenario. 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
