linux-kernel - Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that can be added to dynamically [ver #2]

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]

Date:	Tue, 08 Mar 2016 10:09:05 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	David Howells <dhowells@...hat.com>
Cc:	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that
 can be added to dynamically [ver #2]

On Tue, 2016-03-08 at 14:43 +0000, David Howells wrote:
> The problem boils down to a difficulty in concocting a name that describes a
> complex situation that may change depending on the configuration.  I can make
> it "restrict_link_by_any_system_trusted" if you'd prefer.
> 
> That's why I want "system trusted keyrings" to refer to the builtin and the
> secondary - *and* an extra UEFI keyring if we grow one of those.  It's a
> collection of related keyrings.

Sigh, this is the same discussion we've had for years.  The UEFI keys
should not be trusted to validate the certificates being added to the
IMA keyring.  Neither should the keys on the secondary keyring, unless
specifically IMA Kconfig enabled, be used to validate the certificates
being added to the IMA keyring.  Just because the UEFI keys or the
secondary keyring is enabled, doesn't mean that certificates signed by a
key on either of those keyrings, should be added to the IMA keyring.

The machine/system owner should control which keys can be used to verify
certificates being added to the IMA keyring.

Mimi