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

Powered by Openwall GNU/*/Linux Powered by OpenVZ