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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ