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: <540169d212d09dcc412ef86c127f6c8b74fa676f.camel@HansenPartnership.com>
Date: Fri, 21 Mar 2025 09:19:04 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: lee joey <joeyli.kernel@...il.com>, Lennart Poettering
	 <mzxreary@...inter.de>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Mimi Zohar <zohar@...ux.ibm.com>, 
 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, joeyli <jlee@...e.com>
Subject: Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure
 boot be disabled"

On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote:
> Hi Lennart,
> 
> Lennart Poettering <mzxreary@...inter.de> 於 2025年3月20日 週四 下午8:02寫道：
> > 
> > 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.
> > 
> 
> SB off means that the chain of trust is broken. Which means that all
> mechanisms rely on SB are non-secure. Meanwhile, if the integrity of
> kernel can be guaranteed by other mechanism (e.g. TPM), then mok
> should not be loaded when SB off.

I think the point being made here is that there are other integrity
mechanisms than secure boot which can protect the early boot
environment.

A second argument would be that we still load the UEFI certificates
into the chain, and they have exactly the same early boot guarantees as
the MOK ones, so we're not being consistent: we should load all of them
all the time or none.  The boot envelope still has some protections
even without secure boot or anything else.

The third must be the module one: we've trained users to insert module
signing certificates into MOK.  If they find that mechanism doesn't
work under some possible circumstances they're going to be unhappy.

Part of the problem with that last is with the lockdown creep we're
increasing the chances that users will see turning off secure boot as
the solution to fixing some lockdown problems (say they want hibernate
for instance) so having the kernel be unable to load external modules
in that case when they're trying to relax protections is highly counter
intuitive.

Regards,

James