On 15-10-21 07:22:58, Mimi Zohar wrote: > On Wed, 2015-10-21 at 11:50 +0100, David Howells wrote: > > Mimi Zohar <zo...@linux.vnet.ibm.com> wrote: > > > > > Thinking about the blacklist keyring some more... > > > > Are we talking about a blacklist keyring that userspace can use - or can it > > be only usable by the kernel? > > The blacklist is referenced by the kernel before using a key on either the > .ima or the new .ima_mok keyring to validate a file signature. > > > > My concern is more that keys can be added and removed at run time from > > > either of the .ima or the ima_mok keyrings. The need for a blacklist > > > keyring is to prevent the key from being removed and at a later point > > > re-added. Unfortunately, keys can be added and removed similarly from > > > the > > > blacklist keyring as well. Unless keys can be added, without the ability > > > of removing them, I'm not sure of the benefit of a blacklist keyring. I > > > assume adding and removing keys requires the same write privilege. > > > > The operations that modify the contents of a keyring in some way (link, > > unlink, clear) all operate under Write privilege. That said, we could add > > a > > flag that suppresses unlink and clear on a keyring. This could also > > suppress garbage collection of revoked and invalidated keys. > > Adding the semantics at the keyring level would be better than at the > individual key level. This new flag would prevent keys on the blacklist from > being removed. I like this solution.
Err, what if the key's end-of-life is reached? Revoked or not, it should go. This is more of a question rather than a statement. cheers, 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
