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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <6781.1454949802@warthog.procyon.org.uk>
Date:	Mon, 08 Feb 2016 16:43:22 +0000
From:	David Howells <dhowells@...hat.com>
To:	Mimi Zohar <zohar@...ux.vnet.ibm.com>
Cc:	dhowells@...hat.com, 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?

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.

You can link from any key you have LINK permission on.  Further, add_key() can
add directly.

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

Separately probably makes sense - and marking the blacklist keys with
something that says what is to be checked.

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

Sort of.  It carries a hash string as a description.  One of the patches
matches this with the X.509 TBScertficate hash.  I should look at adding
another patch to check the PE file content hash for kexec also.

> Is it possible to do the equivalent for SKIDs?

Yes.

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

I think you may have misunderstood the point of the question.  Assuming we're
loading a SKID list from userspace, how do we validate the list?  Is it
wrapped in an X.509 cert, a PKCS#7 message or is it a binary blob with an
associated signature?

Or are you proposing the SKID list be built into the kernel at compile time
and not modifiable at runtime?

David