[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1452569755.4776.69.camel@linux.vnet.ibm.com>
Date: Mon, 11 Jan 2016 22:35:55 -0500
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: David Howells <dhowells@...hat.com>
Cc: "Mark D. Baushke" <mdb@...iper.net>,
James Morris <jmorris@...ei.org>,
Marcel Holtmann <marcel@...tmann.org>, petkan@...-labs.com,
linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against
IMA MOK keyring
On Tue, 2016-01-12 at 02:03 +0000, David Howells wrote:
> See the patch ensubjected:
>
> [RFC PATCH 14/15] KEYS: Move the point of trust determination to __key_link()
>
> Search for keyring_alloc and particularly restrict_link_by_ima_mok.
>
> The restriction function cannot currently be cleared or modified by userspace
> - though I have an idea to make it possible to *impose* a restriction through
> keyctl() on any keyring that doesn't yet have a restriction imposed.
>
> The restriction function can impose any restrictions it likes, using the key's
> parsed payload, key type, the current keyring contents and any other keyring
> contents as it wishes in evaluating the trustworthiness of a key.
One assumption is that ima-mok is always enabled, which isn't true and
not the default. Depending on whether it is enabled, the ima keyring
would need to be restricted by "restrict_link_by_ima_mok" or
"restrict_link_by_system_trusted".
The IMA MOK and blacklist are restricted to "public_key_restrict_link".
Does this only allow keys signed by keys on the respective keyring or
also by the system keyring?
As long as the system keyring is limited to just the builtin keys, then
this looks promising. Otherwise, perhaps a separate "builtin" keyring
should be defined.
Mimi
Powered by blists - more mailing lists