Messages in this thread | | | Subject | Re: [RFC PATCH 00/15] KEYS: Restrict additions to 'trusted' keyrings | From | Mimi Zohar <> | Date | Fri, 08 Jan 2016 14:18:33 -0500 |
| |
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@vger.kernel.org/msg03679.html
Mimi
| |