linux-kernel - Re: [PATCH] X.509: Partially revert patch to add validation against IMA MOK 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: <2033.1452447990@warthog.procyon.org.uk>
Date:	Sun, 10 Jan 2016 17:46:30 +0000
From:	David Howells <dhowells@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>
Cc:	dhowells@...hat.com, 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

Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:

> > Is this a NAK on the patch?
> 
> Yes

I would like to counter Mimi's NAK:

 (1) Commit 41c89b64d7184a780f12f2cccdabe65cb2408893 doesn't do what it
     says.  Given the change I want to revert, this bit of the description:


	To successfully import a key into .ima_mok it must be signed by a
	key which CA is in .system keyring.

     is *not* true.  A key in the .ima_mok keyring will *also* allow a key
     into the .ima_mok keyring.  Thus the .ima_mok keyring is redundant and
     should be merged into the .system keyring.

 (2) You can use KEYCTL_LINK to link trusted keys between trusted keyrings
     if the key being linked grants permission.  Add a new key to one open
     keyring and you can then link it across to another.

     Keyrings need to guard against *link* as per my recently posted
     patches.

 (3) In the current model, the trusted-only keyring and trusted-key concept
     ought really to apply only to the .system keyring as the concept of
     'trust' is boolean in this implementation.

     Again, I want to change this as per my recently posted patches.

David