From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755123AbcBHQna (ORCPT ); Mon, 8 Feb 2016 11:43:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50351 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754547AbcBHQnZ (ORCPT ); Mon, 8 Feb 2016 11:43:25 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1454949148.2648.215.camel@linux.vnet.ibm.com> References: <1454949148.2648.215.camel@linux.vnet.ibm.com> <1454943785.2648.195.camel@linux.vnet.ibm.com> <1454938472.2648.173.camel@linux.vnet.ibm.com> <1453318283.2858.27.camel@linux.vnet.ibm.com> <20160119113026.23238.4498.stgit@warthog.procyon.org.uk> <20160119113041.23238.44728.stgit@warthog.procyon.org.uk> <24522.1454513272@warthog.procyon.org.uk> <25433.1454939711@warthog.procyon.org.uk> <14858.1454946832@warthog.procyon.org.uk> To: Mimi Zohar Cc: dhowells@redhat.com, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, petkan@mip-labs.com, linux-kernel@vger.kernel.org Subject: Re: How to add additional blacklist entries? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6780.1454949802.1@warthog.procyon.org.uk> Date: Mon, 08 Feb 2016 16:43:22 +0000 Message-ID: <6781.1454949802@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi Zohar 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