lkml.org 
[lkml]   [2016]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: How to add additional blacklist entries?
From
Date
On Mon, 2016-02-08 at 16:43 +0000, David Howells wrote:
> Mimi Zohar <zohar@linux.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

\
 
 \ /
  Last update: 2016-02-08 20:41    [W:0.088 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site