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] [day] [month] [year] [list]

Message-ID: <Z98qqSoZ-ZkVa1qv@kernel.org>
Date: Sat, 22 Mar 2025 23:24:57 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Lennart Poettering <mzxreary@...inter.de>
Cc: lee joey <joeyli.kernel@...il.com>, 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, Mar 21, 2025 at 09:39:55AM +0100, Lennart Poettering wrote:
> On Fr, 21.03.25 15:13, lee joey (joeyli.kernel@...il.com) 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.
> 
> Why not? as you say, chain of trust is broken: the kernel itself is
> not immediately integrity protected and neither is the firmware. Hence
> filtering out keys in this case is really pointless.

The way I look at this is that unless there is an actual threat scenario
that we protect against by hiding MOK keys, then we should not hide
those keys.

Since I don't find any threat scenarios my reviewed-by holds. Pointless
checks is security by obfuscation, which is not really security.

BR, Jarkko