[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1479745468.2487.60.camel@linux.vnet.ibm.com>
Date: Mon, 21 Nov 2016 11:24:28 -0500
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: Petko Manolov <petkan@...-labs.com>, keyrings@...r.kernel.org,
matthew.garrett@...ula.com, linux-security-module@...r.kernel.org,
linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ima-devel <linux-ima-devel@...ts.sourceforge.net>
Subject: Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys
to secondary keyring
On Mon, 2016-11-21 at 15:17 +0000, David Howells wrote:
> Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
>
> > > > > This allows keys in the UEFI database to be added in secure boot mode
> > > > > for the purposes of module signing.
> > > >
> > > > The key import should not be automatic, it should be optional.
> > >
> > > You can argue this either way. There's a config option to allow you to
> > > turn this on or off. Arguably, this should be split in two: one for the
> > > whitelist (db, MokListRT) and one for the blacklist (dbx).
> >
> > By "config", you're not referring to a Kconfig option, but a UEFI db
> > option, making it hidden/unknown to someone building a kernel. If you
> > really want to add this support, make it clear and easily seen by
> > defining a "restrict_link_by_builtin_or_uefi" function.
>
> No: by "config" I *am* referring to Kconfig.
Good, I found the Kconfig LOAD_UEFI_KEYS option for loading the keys on
the keyring. Lets say that someone does want to use those keys for
kernel modules, but only for kernel modules, not for any other types of
files (eg. kexec kernel image/initramfs)?
Mimi
Powered by blists - more mailing lists