linux-kernel - Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings instead of .ima

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] [day] [month] [year] [list]

Message-ID: <1457474724.5321.170.camel@linux.vnet.ibm.com>
Date:	Tue, 08 Mar 2016 17:05:24 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	Petko Manolov <petkan@...-labs.com>
Cc:	David Howells <dhowells@...hat.com>,
	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 12/12] IMA: Use the the system trusted keyrings
 instead of .ima_mok [ver #2]

On Tue, 2016-03-08 at 18:37 +0200, Petko Manolov wrote:
> On 16-03-08 16:07:00, David Howells wrote:
> > Petko Manolov <petkan@...-labs.com> wrote:
> > 
> > > > How about I change it to a choice-type item, with the following options:
> > > > 
> > > >  (1) No addition.
> > > > 
> > > >  (2) Addition restricted by built-in keyring.
> > > > 
> > > >  (3) Addition restricted by secondary keyring + built-in keyring.
> > > > 
> > > > where the second and third options then depend on the appropriate keyrings 
> > > > being enabled.
> > > 
> > > I would suggest leaving (1) and (3).  Since secondary keyring only accepts
> > > keys signed by certificate in the system keyring I think (2) is redundant.
> > > It adds extra complexity (Kconfig is vague enough already) while it doesn't
> > > increase the overall security by much.
> > 
> > If I remove option (2), that would mean that if you want to allow keys to be 
> > added to .ima if they're signed by the built-in keyring, then you also allow 
> > keys to be added to .ima if they're signed by the secondary keyring if 
> > enabled.
> 
> Exactly.  The primary difference between the built-in and secondary keyring is 
> that the latter is R/W.  Chances are the user want either no addition or need 
> dynamic key add/remove.

Option 1 will prevent ANY keys from being added to the IMA keyring that
were not builtin and loaded by the kernel, similar to the existing
system certificate list.  The keyring itself would need to allow the
builtin keys to be added with the "KEY_ALLOC_BYPASS_RESTRICTION"
override.

Option 2 only allows certificates signed by a key on the builtin keyring
to be added to the IMA keyring.  (This should be the default.)

> I don't have strong opinions against (2).  This is more of a discussion whether 
> we should sacrifice in favor of simplicity or flexibility.

I disagree.  There is a major difference between option 2 and 3.

Mimi