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: <26349.1479376560@warthog.procyon.org.uk>
Date:   Thu, 17 Nov 2016 09:56:00 +0000
From:   David Howells <dhowells@...hat.com>
To:     Petko Manolov <petkan@...-labs.com>
Cc:     dhowells@...hat.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,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>
Subject: Re: [PATCH 4/9] KEYS: Allow unrestricted boot-time addition of keys to secondary keyring

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.

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

Further, possibly I should add an option that allows this to be restricted to
secure boot mode only.

> Same applies to the validation process.

Depends what you mean by "the validation process"?  The use of secure boot at
all?  The checking of signatures on keys?  Module signing?

David