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: <b1b5feaa93922c9b5a8f1a1e41385d266fe640ce.camel@linux.ibm.com>
Date: Tue, 08 Jul 2025 16:52:02 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Lennart Poettering <mzxreary@...inter.de>
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 Fri, 2025-07-04 at 09:34 +0200, Lennart Poettering wrote:
> > That would be preferable to changing the existing expectations to loading the
> > MOK keys when secure boot is not enabled.
> 
> Sorry, but I vehemently disagree, that's a really broken security
> model. SecureBoot on should mean strict rules and, SB off should mean
> relaxed rules, and you are doing it in the opposite way.

We're going around and around in circles, each of us saying the same thing over
and over.  Let's try breaking this down.

For now let's assume there are just two security models, the hybrid security
model of trusted boot transitioning to secure boot and the secure boot only
model.

In the hybrid security model of trusted boot transitioning to secure boot,
you're claiming it is always safe to load vendor keys and/or "local keys",
whether secure boot is enabled or disabled.   This makes sense, because the keys
will be measured and the disk encryption key won't be unsealed (TPM 1.2
terminology) if there are unknown keys.

I'm claiming in the secure boot ONLY model, the default is to use the set of
known builtin trusted keys and to make an exception to allow "vendor keys"
and/or "local keys" IFF secure boot is enabled.  This is a reasonable exception,
relaxing of rules.

With your understanding of "SecureBoot on should mean strict rules and, SB off
should mean relaxed rules ... " there would be no difference if Secure Boot is
enabled or disabled.  For your hybrid security model case this works
perfectly. In the secure boot only case, however, it breaks the existing
security model expectations.

The question is how can both of these security models co-exist?

Mimi