Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings

[Mimi Zohar]

On Fri, 2016-01-08 at 13:54 -0500, Mimi Zohar wrote:
> On Fri, 2016-01-08 at 18:33 +0000, David Howells wrote:
> > Here's a set of patches that changes how keys are determined to be trusted
> > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> > it.  A keyring can then have a flag set (KEY_FLAG_TRUSTED ONLY) that
> > indicates that only keys with this flag set may be added to that keyring.
> > 
> > Further, any time an X.509 certificate is instantiated without this flag
> > set, the certificate is judged against the contents of the system trusted
> > keyring to determine whether KEY_FLAG_TRUSTED should be set upon it.
> > 
> > With these patches, KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed.
> > 
> > The kernel may add implicitly trusted keys to a trusted-only keyring by
> > asserting KEY_ALLOC_BYPASS_RESTRICTION when the key is created, but
> > otherwise the key will only be allowed to be added to the keyring if it can
> > be verified.  The system trusted keyring is not then special in this sense
> > and other trusted keyrings can be set up that are wholly independent of it.
> 
> In order to have a certificate chain of trust on any of these trusted
> keyrings, the system keyring needs to be special.  Even if we permit
> transitive trust, meaning keys on a keyring can be used to validate
> other keys being added to the same keyring, the first key added to a
> trusted keyring needs to be vetted against something.  That something
> needs to be the builtin keys on the system keyring.

Back in November, Mehmet Kayaalp posted a patch for safely adding
additional keys to the system keyring post build and a tool for
re-signing the kernel.

https://www.mail-archive.com/linux-security-module@xxxxxxxxxxxxxxx/msg03679.html

Mimi