linux-kernel - Re: How to add additional blacklist entries?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 08 Feb 2016 11:32:28 -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: How to add additional blacklist entries?

On Mon, 2016-02-08 at 15:53 +0000, David Howells wrote:
> Mimi Zohar <zohar@...ux.vnet.ibm.com> wrote:
> 
> > Right, this patch makes the system blacklist keyring writable by
> > userspace and removes the IMA blacklist.  What I don't understand is how
> > to add a key that is currently on the IMA keyring to the system
> > blacklist? 
> 
> You can do this from userspace with "keyctl link".  Admittedly, this attaches
> the entire key to the blacklist keyring, not just the ID.  But that's
> basically what you're doing at the moment, right.

Does this imply that the key already has to be loaded onto a keyring in
order to link it to the blacklist?   Currently the key doesn't need to
be on the IMA keyring in order for it to be black listed.  The cert can
be verified, that it is signed by a key on the system trusted (or
ima_mok) keyring(s), before directly being added to the IMA blacklist
keyring.

> To simply list the SKID of the key you want to blacklist, another patch will
> be required, but the question is as to what the interface should look like.
> 
> Let's start at the beginning.  First of all, let me ask the following:
> 
>  (1) How is the key-to-be-blacklisted specified?  A copy of the X.509 cert to
>      be blocked?  A signed list of SKIDs to be blocked?  A CRL?

Similar to the TBScertificate hash list, there should be support for a
SKIDs list, either in the same file or separately.

>  (2) How is the blacklist addition to be verified?

As I recall without going back and looking at the patches, you've
defined a new key type for just the TBScertficate hash without a
payload.  Is it possible to do the equivalent for SKIDs?  In both cases,
these new key type(s) would need to be signed by a key on the system
keyring (now called the builtin keyring) for it to be added to the
blacklist.

Mimi