On 15-10-20 08:48:20, Mimi Zohar wrote:
> On Tue, 2015-10-20 at 10:22 +0300, Petko Manolov wrote:
> >
> > This is all we've been using the blacklist keyring so far. By semantics it
> > is system-wide keyring so maybe the commit message should be changed.
> > Nothing prevents others from using it.
> >
> > The problem is that an IMA option enables the creation of this keyring,
> > which makes it IMA specific for the moment. If it is decided that the
> > blacklist keyring should be detached from it's IMA bonds then i guess two
> > things should happen: 1) broader discussion (perhaps involving David); and
> > 2) modifying the patches;
> >
> > BTW, same applies for the MOK keyring. If you want these to be more
> > generally used i assume a discussion is in order.
>
> I understand these keyrings could be useful for the more general case, but
> lets first discuss IMA. I'm trying to understand why the blacklist is tied
> so
> closely to just the .ima_mok keyring in the Kconfig. Is the need for
> blacklisting keys any less if the key is on the .ima keyring vs. the .ima_mok
> keyring?
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.
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
