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 22:33:39 +0200
From:	Petko Manolov <petkan@...-labs.com>
To:	David Howells <dhowells@...hat.com>
Cc:	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org, mdb@...iper.net
Subject: Re: [PATCH] X.509: Partially revert patch to add validation against
 IMA MOK keyring

On 16-01-10 17:46:30, David Howells 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

This is correct, but is also the desired result.  Assume that you have multi 
tenant machine where the manufacturer signs the owner's/tenant's key and those 
also need to sign other sub-tenant keys.  One can't put them on the system 
keyring so they end up in .ima_mok.

>      into the .ima_mok keyring.  Thus the .ima_mok keyring is redundant and
>      should be merged into the .system keyring.

I share Mimi's opinion that .system keyring must be static and ultimately 
trusted.  Since .ima_mok is a dynamic keyring, merging them will break the 
semantics.

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

I'd rather rely on a certificate being properly signed in order to land in a 
particular keyring, rather than being linked based on permissions model.

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

The .system keyring should be read-only, IOW static.  Only keys present at build 
time should go there.  Everything else goes to the machine owner keyring (MOK) 
or whatever the name.  MOK should be read-write and (maybe) hold only second 
level CAs, signed by CA in the system keyring.

I introduced .ima_mok just because my work had limited scope at the time and i 
consider the name as misleading.

The way i see kernel's keyrings:

                           /---> .ima
            /----> MOK ---<
.system ---<               \---> .evm
            \----> BL       \---> .whatever need to be "trusted"

The graph could be a lot more complex, but to wrap your head around the idea 
think of big ass machine with years of uptime and multiple simultaneous users, 
all pre-installed files IMA signed, ability to add other IMA signed packages on 
the fly.  The machine must be FIPS certifiable, etc.  A terabit switching 
machine should be able to do that and there are real users for this scenario out 
there.

The black-list keyring is equally important so one can revoke CAs if need be.  
On the fly.

		Petko