lkml.org 
[lkml]   [2014]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH v5 4/4] KEYS: define an owner trusted keyring
From
Date
On Mon, 2014-06-09 at 15:13 +0300, Dmitry Kasatkin wrote: 
> On 03/06/14 20:58, Mimi Zohar wrote:
> > Instead of allowing public keys, with certificates signed by any
> > key on the system trusted keyring, to be added to a trusted
> > keyring, this patch further restricts the certificates to those
> > signed by a particular key on the system keyring.
> >
> > When the UEFI secure boot keys are added to the system keyring, the
> > platform owner will be able to load their key in one of the UEFI DBs
> > (eg. Machine Owner Key(MOK) list) and select their key, without
> > having to rebuild the kernel.
> >
> > This patch defines an owner trusted keyring, a new boot command
> > line option 'keys_ownerid=', and defines a new function
> > get_system_or_owner_trusted_keyring().
>
> Hello,
>
> The functionality of this entire patch can be replaced by only ~2 lines
> of code in x509_request_asymmetric_key()
>
> if (keys_ownerid || strcmp(keys_ownerid, id))
> return -EPERM;
>
> Right?

Are you suggesting only add the one matching key to the system keyring?

The original patch compared the builtin key being loaded onto the system
keyring and, if it matched the requested key, also added the key to the
owner keyring. This version waits for all the builtin keys to be loaded
onto the system keyring, and in the future the UEFI DB keys, before
adding the matched key to the owner keyring. In this version, the keys
are already on the system keyring. So no, your two lines would not
work.

Mimi







\
 
 \ /
  Last update: 2014-06-09 15:21    [W:0.083 / U:9.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site