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] [day] [month] [year] [list]
Message-Id: <1565015295.11223.147.camel@linux.ibm.com>
Date:   Mon, 05 Aug 2019 10:28:15 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Jia Zhang <zhang.jia@...ux.alibaba.com>, dhowells@...hat.com,
        dmitry.kasatkin@...il.com
Cc:     keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Mark D. Baushke" <mdb@...iper.net>,
        Petko Manolov <petkan@...-labs.com>
Subject: Re: [PATCH] ima: Allow to import the blacklisted cert signed by
 secondary CA cert

On Fri, 2019-08-02 at 09:42 +0800, Jia Zhang wrote:
> 
> On 2019/8/2 上午6:57, Mimi Zohar wrote:
> > Hi Jia,
> > 
> > On Thu, 2019-08-01 at 09:23 +0800, Jia Zhang wrote:
> >> Similar to .ima, the cert imported to .ima_blacklist is able to be
> >> authenticated by a secondary CA cert.
> >>
> >> Signed-off-by: Jia Zhang <zhang.jia@...ux.alibaba.com>
> > 
> > The IMA blacklist, which is defined as experimental for a reason, was
> > upstreamed prior to the system blacklist.  Any reason you're not using
> > the system blacklist?  Before making this sort of change, I'd like
> > some input from others.
> 
> In our trusted cloud service, the IMA private key is controlled by
> tenant for some reason. Some unprofessional operations made by tenant
> may lead to the leakage of IMA private key. So the need for importing
> the blacklisted is necessary,without system/kexec reboot, on the
> contrary, the system blacklist needs a kernel rebuild and system/kexec
> reboot, without runtime and fine-grained control.
> 
> The secondary CA cert has a similar story, but it is not controlled by
> tenant. It is always imported during system/kexec boot to serve
> importing IMA trusted cert and IMA blacklisted cert.

Before expanding the set of keys permitted to blacklist a key on the
IMA keyring, there needs to be a way of differentiating how keys may
be used.  The same certificate should not be allowed to be loaded onto
both the IMA and the IMA blacklist keyrings for obvious reasons.

The normal way of blacklisting a key is by using CRLs.  I'm not
recommending adding full CRL support in the kernel, but using the key
usage extension to differentiate who may sign a certificate being
black listed.  Please refer to section "4.2.1.3.  Key Usage", in
particular the cRLSign bit.

thanks,

Mimi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ