On 15-10-21 11:50:27, 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?
So far the discussion has been entirely in IMA context. Keys can be shuffled around by userspace (by root and non-root users) but their only consumer is the IMA code. That said, nothing prevents these keyrings to be used by the rest of the system. I guess sooner or later we'll end up making them global. Having more flexible CA hierarchy in the kernel is a good thing IMHO. > > 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. Agreed. If it is needed to preserve revoked key from being GCed or unlinked, i assume we'll need another flag. Current permissions model can't guarantee it. > Note, however, that keyring searches also skip revoked and invalidated keys, > so that would also need dealing with. That too. Some scenarios may require listing all revoked keys. I am still waiting to hear whether we'll need this functionality. I assume you are not opposed to the idea of introducing such flag(s) if needed? > > (We previously resolved the problem of keyrings being removed by userspace, > > even by a privileged user, by dot prefixing the keyrings.) > > That doesn't stop keys being addressed directly for invalidation and > revocation, but you can probably manage that with permissions. In this particular case we only deal with trusted keyrings so this is of no concern. 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
