Bug#865277: Please disable CONFIG_INTEGRITY_TRUSTED_KEYRING

[Matthew Garrett <mjg59@google.com>]

Package: linux
Severity: wishlist

CONFIG_INTEGRITY_TRUSTED_KEYRING is documented as:

           This option requires that all keys added to the .ima and
           .evm keyrings be signed by a key on the system trusted
           keyring.

This means that it's impossible to add keys to the .ima or .evm
keyrings unless those keys are signed by a key in the trusted keyring.
The trusted keyring is defined at compile time as containing only
debian/certs/benh@debian.org.cert.pem, so ima and evm keys can only be
added if they're signed by Debian.

This isn't ideal for a general purpose binary distribution, and
doesn't make a great deal of sense anyway. IMA will do nothing by
default unless a policy is configured at boot time, which means that
it requires a trusted boot chain that will load the initial IMA
policy. It's reasonable to assert that anything trusted to load policy
should also be trusted to load the initial trusted keyset.

Userspace has two choices: they can either add raw keys to the IMA
keyring and then lock it down so new keys can't be added, or they can
create a new keyring containing the trusted certificate chain and lock
it down, and then restrict the IMA keyring with
KEYCTL_RESTRICT_KEYRING such that it will only load keys signed by
keys in the new trusted keyring. The second case is equivalent to the
behaviour where CONFIG_INTEGRITY_TRUSTED_KEYRING is enabled, except
that a trusted keyring under user control is used rather than one
under Debian's control. This allows the local admin to decide which
keys they trust, whereas right now Debian is the only organisation
able to make that decision for the user.