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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
