Message-ID: <1457449745.5321.141.camel@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH 11/12] certs: Add a secondary system keyring that
 can be added to dynamically [ver #2]
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date: Tue, 08 Mar 2016 10:09:05 -0500
In-Reply-To: <449.1457448192@warthog.procyon.org.uk>
References: <1457447480.5321.115.camel@linux.vnet.ibm.com>
	 <1457402735.5321.14.camel@linux.vnet.ibm.com>
	 <20160304150022.17121.34501.stgit@warthog.procyon.org.uk>
	 <20160304150142.17121.56666.stgit@warthog.procyon.org.uk>
	 <30699.1457442839@warthog.procyon.org.uk>
	 <449.1457448192@warthog.procyon.org.uk>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1082
Lines: 21

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