Date:	Mon, 08 Feb 2016 14:28:02 -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 16:43 +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.
> 
> You can link from any key you have LINK permission on.  Further, add_key() can
> add directly.

Oh, for some reason I thought the system blacklist keyring was limited
to the new key type with just a description.   I was able to add, but
also remove a key from the system blacklist.   I guess the KEY_FLAG_KEEP
is not set on the system blacklist.

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

The keys being added to the IMA keyring are signed x509 certs (eg.
openssl ca -ss_cert).  It would be nice to be able to include the skid
in the description, without a payload, and sign that.  I have no idea if
that Is possible or if it makes sense.  I'm open to suggestions.

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

No, we definitely want to be able to blacklist keys at run time.

Mimi

Powered by blists - more mailing lists