linux-kernel - Re: [PATCH 1/4] KEYS: define an owner trusted keyring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1402405679.5350.17.camel@dhcp-9-2-203-236.watson.ibm.com>
Date:	Tue, 10 Jun 2014 09:07:59 -0400
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Josh Boyer <jwboyer@...hat.com>
Cc:	Dmitry Kasatkin <d.kasatkin@...sung.com>, dhowells@...hat.com,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmitry.kasatkin@...il.com,
	mjg59@...f.ucam.org
Subject: Re: [PATCH 1/4] KEYS: define an owner trusted keyring

On Tue, 2014-06-10 at 08:24 -0400, Josh Boyer wrote: 
> On Tue, Jun 10, 2014 at 11:48:15AM +0300, Dmitry Kasatkin wrote:
> > From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> > 
> > 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().
> > 
> > Signed-off-by: Mimi Zohar<zohar@...ux.vnet.ibm.com>
> > ---
> >  Documentation/kernel-parameters.txt      |  5 ++
> >  crypto/asymmetric_keys/x509_public_key.c |  4 +-
> >  include/keys/owner_keyring.h             | 27 ++++++++++
> >  init/Kconfig                             | 10 ++++
> >  kernel/Makefile                          |  1 +
> >  kernel/owner_keyring.c                   | 85 ++++++++++++++++++++++++++++++++
> >  6 files changed, 131 insertions(+), 1 deletion(-)
> >  create mode 100644 include/keys/owner_keyring.h
> >  create mode 100644 kernel/owner_keyring.c
> > 
> > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> > index 7116fda..f90d31d 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -1434,6 +1434,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> >  			use the HighMem zone if it exists, and the Normal
> >  			zone if it does not.
> >  
> > +	keys_ownerid=[KEYS] This parameter identifies a specific key on
> > +			the system trusted keyring to be added to the
> > +			owner trusted keyring.
> > +			format: id:<keyid>
> > +
> 
> I'm fairly sure this runs into the same problems I mentioned previously
> in the secure boot context.  Namely that a remote attacker could modify
> keys_ownerid in the bootloader config file if they gained root access.

Yes, someone could specify a key not in the UEFI DB or builtin, but it
would not do them much good.  The "keys_ownerid" searches the
UEFI/builtin keys for the keyid.

Mimi

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