linux-kernel - Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary 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: <1479737095.2487.34.camel@linux.vnet.ibm.com>
Date:   Mon, 21 Nov 2016 09:04:55 -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 Thu, 2016-11-17 at 09:56 +0000, David Howells wrote:
> Petko Manolov <petkan@...-labs.com> wrote:
> 
> > On 16-11-16 18:11:13, David Howells wrote:
> > > Allow keys to be added to the system secondary certificates keyring during 
> > > kernel initialisation in an unrestricted fashion.  Such keys are implicitly 
> > > trusted and don't have their trust chains checked on link.
> > 
> > Well, I for one do not explicitly trust these keys.  I may even want to 
> > completely remove or replace them.
> 
> Fine be me.  However, if you remove them all I would guess that you cannot
> perform a secure boot.
> 
> Note that it's to be expected that the keys being loaded from the UEFI
> database cannot have their signatures checked - which is why they would have
> to be implicitly trusted.  For the same reason, the kernel does not check the
> signatures on the keys compiled into the kernel image.

Sigh, we've been here before, discussed this before.  Different keys
should be trusted at different levels.  Nothing has changed.  Just
because I trust a key in UEFI for UEFI, doesn't mean that I trust that
same key once the kernel has booted.

This time not only are you bringing the keys from UEFI up to the kernel,
but by adding these keys to the secondary trusted keyring, they are
allowed to add other keys they've signed to the secondary trusted
keyring.

If the UEFI keys are just for verifying kernel modules, why not define a
separate UEFI keyring, which can be used, if enabled, just for verifying
kernel modules, instead of affecting all signature verification?

IMA's root of trust goes back to UEFI, but transitions to the builtin
kernel keyring and, if enabled,  the secondary keyring on boot.

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

Mimi