Re: [PATCH 00/10] KEYS: Change how keys are determined to be trusted

[Josh Boyer]

On Wed, Oct 21, 2015 at 1:02 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 2015-10-21 at 16:13 +0100, 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 is removed.  The kernel may add
>> implicitly trusted keys to a trusted-only keyring by asserting
>> KEY_ALLOC_TRUSTED when the key is created,
>
> Ok, but only the x509 certificates built into the kernel image should be
> automatically trusted and can be added to a trusted keyring, because the
> kernel itself was signed (and verified).  These certificates extend the
> (UEFI) certificate chain of trust that is rooted in hardware to the OS.

That doesn't sound accurate to me.  The cert built into the kernel
image doesn't extend the UEFI certificates.  In most cases, it is a
ephemeral cert that is automatically generated at kernel build time
and then discarded.  It is not chained to or derived from any of the
UEFI certs stored in the db (or mok) variables.  The built-in cert is
used for module loading verification.  I agree that it should be
trusted, but not really for the reason you list.  Perhaps you meant
the key that the PE image of the kernel is signed with?  If so, the
kernel doesn't load that.  Only shim (and grub2 via shim) read that
key.

However, that does bring up the UEFI db/mok certs and how to deal with
those.  The out-of-tree patches we have add them to the system keyring
as trusted keys.  We can modify the patches to use KEY_ALLOC_TRUSTED
to preserve that functionality I suppose.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/