linux-kernel - Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"

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: <aGYurikYK1ManAp3@gardel-login>
Date: Thu, 3 Jul 2025 09:18:06 +0200
From: Lennart Poettering <mzxreary@...inter.de>
To: Mimi Zohar <zohar@...ux.ibm.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>,
	Roberto Sassu <roberto.sassu@...wei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	Eric Snowberg <eric.snowberg@...cle.com>,
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	linux-integrity@...r.kernel.org, keyrings@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Lee, Chun-Yi" <joeyli.kernel@...il.com>
Subject: Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure
 boot be disabled"

On Mi, 02.07.25 21:40, Mimi Zohar (zohar@...ux.ibm.com) wrote:

> On Thu, 2025-03-20 at 13:02 +0100, Lennart Poettering wrote:
> > This reverts commit 92ad19559ea9a8ec6f158480934ae26ebfe2c14f.
> >
> > This original commit this reverts creates a strange situation: it
> > ensures more restrictive behaviour if SecureBoot is off then when it
> > is on, which is the opposite of what one would expect.
> >
> > Typically, one would expect that if SB is off the validation of
> > resources during the pre-kernel and kernel initialization is less
> > restrictive, not more restrictive. But this check turned the world on
> > its head.
>
> Hi Lennart,
>
> I'm really sorry for the long delay ...
>
> >From an IMA perspective, the default is to only trust keys built into the kernel
> or certificates signed by the builtin keys and loaded onto the
> .secondary_trusted_keys keyring.
>
> The ability of loading MOK keys onto the .machine keyring and linked to the
> .secondary_trusted_keys keyring is an exception based on the assumption that
> that there is a secure boot chain of trust.  Allowing untrusted keys onto or
> linked to the .secondary_trusted_keys keyring, would potentially allow loading
> code signing keys onto the IMA keyring signed by untrusted MOK keys.
>
> I was really hesitant to allow this exception of loading MOK keys onto the
> .machine keyring in the first place.  I'm now even more concerned.
>
> This is not just an issue of being more or less restrictive, but of adding a new
> integrity gap when one didn't exist previously.

But we are talking of the case here where SecureBoot is *off*,
i.e. there is a concious decision in place that there is no trust
chain, and that the firmware *happily* *already* accepts unsigned boot
loaders/kernels and just runs with them. If SecureBoot is already off,
then an attacker can patch around in the kernel invoked at boot
completely freely anyway, there is *no* authentication done. Hence
it's really weird to then insist that the path into the kernel keyring
via mok keys is off in *only* this case, because an attacker can get
into that anyway in this case, it's just a lot more cumbersome.

It's really strange that currently when people ask for tight security
(i.e. SB on) the linux kernel is super relaxed and allows any keys to
be inserted, but if people ask for security checks to be off (i.e. SB
off) the kernel starts being super strict and doesn't allow any keys
to propagate into mok. That's really confusing and contradictory, no?

Lennart

--
Lennart Poettering, Berlin