On 15-10-20 11:21:43, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 17:43 +0300, Petko Manolov wrote:
> 
> > 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.
> 
> The concept of black listing a key is a common concept and should be 
> understood.

Well, it should.

> Thinking about the blacklist keyring some more...  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.  (cc'ing David Howells)

As far as i know there is no concept of write-once to a keyring in the kernel.  
David will correct me if i am wrong.  I wonder how hard would it be to add such 
functionality, in case it is missing?

Ideally a revoked key should stay in .blacklist until it expire or the system 
is 
rebooted.

> (We previously resolved the problem of keyrings being removed by userspace, 
> even by a privileged user, by dot prefixing the keyrings.)
> 
> > In short - do you want me to add separate options for the two keyrings in 
> > Kconfig?
> 
> I would think so, but first lets address the concerns above.

Yeah, splitting the option is trivial.


                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

Reply via email to