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: <7265798627defd6111af4e3a863b8525b07c511d.camel@linux.ibm.com>
Date:   Mon, 28 Mar 2022 09:28:14 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     joeyli <jlee@...e.com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Philipp Rudo <prudo@...hat.com>, Baoquan He <bhe@...hat.com>,
        Alexander Egorenkov <egorenar@...ux.ibm.com>,
        AKASHI Takahiro <takahiro.akashi@...aro.org>,
        James Morse <james.morse@....com>,
        Dave Young <dyoung@...hat.com>,
        Kairui Song <kasong@...hat.com>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-modules@...r.kernel.org,
        keyrings@...r.kernel.org, linux-security-module@...r.kernel.org,
        stable@...nel.org, Eric Snowberg <eric.snowberg@...cle.com>,
        Michal Suchánek <msuchanek@...e.de>,
        Luis Chamberlain <mcgrof@...nel.org>
Subject: Re: [PATCH 4/4] module, KEYS: Make use of platform keyring for
 signature verification

On Mon, 2022-03-28 at 18:15 +0800, joeyli wrote:

Hi Joey,

> Hi Mimi,
> 
> Sorry for bother you for this old topic.

Cc'ing Luis the kernel modules maintainer.

> 
> On Tue, Feb 15, 2022 at 09:47:30PM +0100, Michal Suchánek wrote:
> > Hello,
> > 
> > On Tue, Feb 15, 2022 at 03:08:18PM -0500, Mimi Zohar wrote:
> > > [Cc'ing Eric Snowberg]
> > > 
> > > Hi Michal,
> > > 
> > > On Tue, 2022-02-15 at 20:39 +0100, Michal Suchanek wrote:
> > > > Commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature verify")
> > > > adds support for use of platform keyring in kexec verification but
> > > > support for modules is missing.
> > > > 
> > > > Add support for verification of modules with keys from platform keyring
> > > > as well.
> > > 
> > > Permission for loading the pre-OS keys onto the "platform" keyring and
> > > using them is limited to verifying the kexec kernel image, nothing
> > > else.
> > 
> > Why is the platform keyring limited to kexec, and nothing else?
> > 
> > It should either be used for everything or for nothing. You have the
> > option to compile it in and then it should be used, and the option to
> > not compile it in and then it cannot be used.
> > 
> > There are two basic use cases:
> > 
> > (1) there is a vendor key which is very hard to use so you sign
> > something small and simple like shim with the vendor key, and sign your
> > kernel and modules with your own key that's typically enrolled with shim
> > MOK, and built into the kernel.
> > 
> > (2) you import your key into the firmware, and possibly disable the
> > vendor key. You can load the kernel directly without shim, and then your
> > signing key is typically in the platform keyring and built into the
> > kernel.
> >
> 
> In the second use case, if user can enroll their own key to db either before
> or after hardware shipping. And they don't need shim because they removed
> Microsoft or OEM/ODM keys.  Why kernel can not provide a Kconfig option to
> them for trusting db keys for verifying kernel module, or for IMA (using CA
> in db)?
>  
> In the above use case for distro, partner doesn't need to re-compiler distro
> kernel. They just need to re-sign distro kernel and modules. Which means
> that the partner trusted distro. Then the partner's key in db can be used to
> verify kernel image and also kernel module without shim involve.

>From what I understand, distros don't want customers resigning their
kernels.  If they did, then they could have enabled the
CONFIG_SYSTEM_EXTRA_CERTIFICATE, which would load the keys onto the
"builtin" keyring, and anything signed by those keys could be loaded
onto the secondary keyring.  (Of course CONFIG_SYSTEM_EXTRA_CERTIFICATE
would need to be fixed/updated.)

We've gone through "what if" scenarios before.  My response then, as
now, is post it as a patch with the real motivation for such a change.

thanks,

Mimi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ