[PATCH 0/7] Add CA enforcement keyring restrictions

[Elaine Palmer]

On 2022/11/04 9:20 AM, Coiby Xu wrote:
> Hi Eric,
>
> I wonder if there is any update on this work? I would be glad to do
> anything that may be helpful including testing a new version of code.
>
Hi Coiby,

Yes, this discussion got stuck when we couldn't agree on one of the
following options:

(A) Filter which keys from MOK (or a management system) are loaded
    onto the .machine keyring. Specifically, load only keys with
    CA+keyCertSign attributes.

(B) Load all keys from MOK (or a management system) onto the
    .machine keyring. Then, subsequently filter those to restrict
    which ones can be loaded onto the .ima keyring specifically.

The objection to (A) was that distros would have to go through
two steps instead of one to load keys. The one-step method of
loading keys was supported by an out-of-tree patch and then by
the addition of the .machine keyring.

The objection to (B) was that, because the .machine keyring is now
linked to the .secondary keyring, it expands the scope of what the
kernel has trusted in the past. The effect is that keys in MOK
have the same broad scope as keys previously restricted to
.builtin and .secondary. It doesn't affect just IMA, but the rest
of the kernel as well.

I would suggest that we can get unstuck by considering:

(C) Defining a systemd (or dracut module) to load keys onto the
    .secondary keyring

(D) Using a configuration option to specify what types of
    .machine keys should be allowed to pass through to the
    .secondary keyring.
   
    The distro could choose (A) by allowing only
    CA+keyCertSign keys.

    The distro could choose (B) by allowing any kind
    of key.

We all seemed to agree that enforcing key usage should be
implemented and that a useful future effort is to add policies
to keys and keyrings, like, "This key can only be used for
verifying kernel modules."

I hope we can come to an agreement so work can proceed and IMA
can be re-enabled.

-Elaine Palmer