linux-kernel - Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for signatures verification

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: <f0b37bc55ed3c02569c74f0fbdb6afa8efd329e2.camel@HansenPartnership.com>
Date: Wed, 04 Jun 2025 13:34:53 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Eric Snowberg <eric.snowberg@...cle.com>, Vitaly Kuznetsov
	 <vkuznets@...hat.com>
Cc: "linux-security-module@...r.kernel.org"
 <linux-security-module@...r.kernel.org>, "linux-integrity@...r.kernel.org"
 <linux-integrity@...r.kernel.org>, "linux-modules@...r.kernel.org"
 <linux-modules@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "linux-doc@...r.kernel.org"
 <linux-doc@...r.kernel.org>, "keyrings@...r.kernel.org"
 <keyrings@...r.kernel.org>, David Howells <dhowells@...hat.com>, David
 Woodhouse <dwmw2@...radead.org>, Jonathan Corbet <corbet@....net>, Luis
 Chamberlain <mcgrof@...nel.org>,  Petr Pavlu <petr.pavlu@...e.com>, Sami
 Tolvanen <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>,
 Mimi Zohar <zohar@...ux.ibm.com>, Roberto Sassu <roberto.sassu@...wei.com>,
 Dmitry Kasatkin <dmitry.kasatkin@...il.com>,  Paul Moore
 <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, "Serge E. Hallyn"
 <serge@...lyn.com>,  Peter Jones <pjones@...hat.com>, Robert Holmes
 <robeholmes@...il.com>, Jeremy Cline <jcline@...hat.com>,  Coiby Xu
 <coxu@...hat.com>, Gerd Hoffmann <kraxel@...hat.com>
Subject: Re: [PATCH RFC 0/1] module: Optionally use .platform keyring for
 signatures verification

On Wed, 2025-06-04 at 17:01 +0000, Eric Snowberg wrote:
> > On Jun 2, 2025, at 7:25 AM, Vitaly Kuznetsov <vkuznets@...hat.com> 
> > The use-case: virtualized and cloud infrastructure generally
> > provide an ability to customize SecureBoot variables, in
> > particular, it is possible to bring your own SecureBoot 'db'. This
> > may come handy when a user wants to load a third party kernel
> > module (self built or provided by a third party vendor) while still
> > using a distro provided kernel. Generally, distro provided kernels
> > sign modules with an ephemeral key and discard the private part
> > during the build. While MOK can sometimes be used to sign something
> > out-of-tree, it is a tedious process requiring either a manual
> > intervention with shim or a 'certmule' (see
> > https://blogs.oracle.com/linux/post/the-machine-keyring). In
> > contrast, the beauty of using SecureBoot 'db' in this scenario is
> > that for public clouds and virtualized infrastructure it is
> > normally a property of the OS image (or the whole
> > infrastructure/host) and not an individual instance; this means
> > that all instances created from the same template will have 'db'
> > keys in '.platform' by default.
> 
> Hasn’t this approach been rejected multiple times in the past?

Well not rejected, just we always thought that people (like me) who
take control of their secure boot systems are a tiny minority who can
cope with being different.  I have to say the embedding of all the
variable manipulations in shim made it quite hard.  However you can use
the efitools KeyTool to get a graphical method for adding MoK keys even
in the absence of shim.

The question is, is there a growing use case for db users beyond the
exceptions who own their own keys on their laptop, in which case we
should reconsider this.

Regards,

James