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: <1454938472.2648.173.camel@linux.vnet.ibm.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ