linux-kernel - Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2]

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:	Mon, 08 Feb 2016 08:34:32 -0500
From:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:	David Howells <dhowells@...hat.com>
Cc:	linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
	petkan@...-labs.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2]

On Wed, 2016-02-03 at 15:27 +0000, David Howells wrote:
> Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> 
> > >  (3) The ability to configure a list of blacklisted hashes into the kernel
> > >      at build time.  This is done by setting
> > >      CONFIG_SYSTEM_BLACKLIST_HASH_LIST to the filename of a list of hashes
> > >      that are in the form:
> > > 
> > > 	"<hash>", "<hash>", ..., "<hash>"
> > > 
> > >      where each <hash> is a hex string representation of the hash and must
> > >      include all necessary leading zeros to pad the hash to the right size.
> > 
> > Is the output of "keyctl print" the hex string representation?
> 
> No, there is no payload and no read method.  "keyctl desc" will return the hex
> string representation.
> 
> >  Update keys documentation?
> 
> Not a bad idea, but it should probably go in a separate document, along with
> info about asymmetric keys.
> 
> > > The blacklist cannot currently be modified by userspace, but it will be
> > > possible to load it, for example, from the UEFI blacklist database.
> > 
> > When loading the UEFI blacklist database is enabled, it should be
> > configurable.
> 
> Probably.  That patch isn't added yet though.
> 
> > > In the future, it should also be made possible to load blacklisted
> > > asymmetric keys in here too.
> > 
> > Please update to reflect patch 3/20 "X.509: Allow X.509 certs to be
> > blacklisted" adds this support.
> 
> Changed to:
> 
> 	A later commit will make it possible to load blacklisted asymmetric
> 	keys in here too.

As you said, only the kernel can load keys on the blacklist, not
userspace, and the patch for loading the UEFI blacklist keys on the
system blacklist keyring is not included in this patch set, wouldn't it
be better to separate the concept of a general blacklist keyring from
the concept of trust?   In addition, this patch set removes the IMA
blacklist without any method for adding blacklisted IMA keys to the
system blacklist keyring.   I suggest a separate blacklist patch set
that adds support: for a system blacklist keyring, different types of
keys being black listed, allow userspace to load blacklisted keys on the
system blacklist keyring,  convert the ima_blacklist to use the general
system blacklist keyring and, optionally, include the UEFI blacklist
keys on the blacklist keyring.

This patch set would then be limited to "how certificates/keys are
determined to be trusted."  By separating out the blacklist keyring from
the issue of trust, you'll have smaller patch sets that can more easily
be reviewed. (Reviewing anything having to do with certificates is
difficult enough.)  It would also allow you to upstream the two patch
sets independently of each other.

Mimi