On 15-10-20 10:13:34, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 16:24 +0300, Petko Manolov wrote:
> >
> > The code does not ties these keyrings around IMA. The way i've done it,
> > they are actually system wide keyrings and any other subsystem may use them.
> >
> > Since there was no general discussion (hence agreement) that the Linux
> > kernel need these keyrings i've put them within the IMA config options.
> > For
> > now only IMA users interested in creating CA hierarchy should use them.
> >
> > > Basically, I'm trying to better understand the use case scenario.
> >
> > To build CA hierarchy we basically need two things:
> >
> > - system wide keyring writable at runtime, i.e. .ima_mok;
> > - system wide blacklist keyring writable at runtime, i.e. .blacklist;
> >
> > .system is read-only and populated at kernel build time. During the
> > lifetime (as in runtime) of the machine we need to dynamically add tenant's
> > certificates and IMA keys. Without .ima_mok this can not be done easily
> > because most of tenant's certificates are not available at krenel build
> > time. Most of these have one year of validity and must be replaced, while
> > the router's uptime is typically much longer.
> >
> > While the current kernel key code handles CA expiration it does not handle
> > blacklisted certificates or keys. The patch add checks to this keyring so
> > any CA that has been compromised can't harm the system.
> >
> > .ima_mok and .blacklist are IMA-enabled features for the moment not by
> > semantics, but by policy. I do think they should become system wide one
> > day
> > and there are good reasons to do so.
>
> All very good! As we discussed, this can and should be upstreamed initially
> for IMA.
>
> My question, however, has more to do with the last paragraph of the patch
> description which says, "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."
>
> If the IMA blacklist keyring is for ALL IMA keys, those on the the original
> .ima keyring and those on the .ima_mok keyring, then why is the Kconfig tied
> to the .ima_mok keyring? Does it make sense to have a blacklist keyring
> without the .ima_mok keyring? Should there be a separate Kconfig blacklist
> keyring option?
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.
In short - do you want me to add separate options for the two keyrings in
Kconfig?
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
