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]

Date:	Sun, 10 Jan 2016 20:33:38 +0000
From:	David Howells <dhowells@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>
Cc:	dhowells@...hat.com, 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

David Howells <dhowells@...hat.com> wrote:

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

 (4) Marcel asked to have user-based 'trusted' keyrings - where userspace
     can load a keyring up and then mark it as 'trusted' thereby limiting
     further additions - for the use with kernel-based TLS.

     These would *not* depend on the .system keyring.  Unless we're willing
     to store the root CA certificate for the world in the kernel, we can't
     really do that.

David