Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings
From: Mimi Zohar
Date: Fri Jan 08 2016 - 14:21:28 EST
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.