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

[Mimi Zohar <zohar@linux.ibm.com>]

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