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: <87tt4unw1w.fsf@redhat.com>
Date: Thu, 05 Jun 2025 15:43:23 +0200
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>, Eric Snowberg
 <eric.snowberg@...cle.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

James Bottomley <James.Bottomley@...senPartnership.com> writes:

> On Thu, 2025-06-05 at 09:54 +0200, Vitaly Kuznetsov wrote:
>> One additional consideration is the fact that we already trust 'db'
>> for dm-verity (since 6fce1f40e951) and kexec (since 278311e417be) and
>> especially the later gives someone who is able to control 'db' access
>> to CPL0; a 'db'-signed module (IMO) wouldn't change much.
>
> Well, the kexec case is because kexec has to verify the new kernel as
> shim would and shim would use the UEFI keys.  The dm-verity one was
> added for a cloud use case by pressuring the maintainers in spite of
> the objection to using the platform keyring (it went to dm-devel only
> so not many integrity people saw it):
>
> https://lore.kernel.org/all/20240617220037.594792-1-luca.boccassi@gmail.com/
>
> The point here is I do think the cloud use case is legitimate, but it
> can't be supported simply by ignoring the bare metal security domain
> separation concerns of the integrity community.  The argument that
> distros have done it so it must be safe isn't really a winning one
> (especially as there's no clear explanation of why they did it).  So
> either you need a better argument or we need a way to support both sets
> of communities ... which is why I was wondering about a runtime
> differentiator.

So far, I got two 'runtime' ideas:
- Observe MokListTrustedRT and distrust .platform when it is
non-empty. This can, of course, be combine with a Kconfig for those, who
do not want it at all.

and/or
- Sysctl toggle. Keep things as they are by default but make .platform
trusted (either for modules or for everything) when switched 'on'. This
can (optionally) by combined with a previous idea and have e.g. an
'auto' state for the toggle which follows MokListTrustedRT.

-- 
Vitaly