mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: lee joey <joeyli.kernel@gmail.com>,
	Lennart Poettering <mzxreary@0pointer.de>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
	Mimi Zohar <zohar@linux.ibm.com>,
	 Roberto Sassu <roberto.sassu@huawei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Eric Snowberg <eric.snowberg@oracle.com>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	 linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	 linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, joeyli <jlee@suse.com>
Subject: Re: [PATCH] Revert "integrity: Do not load MOK and MOKx when secure boot be disabled"
Date: Fri, 21 Mar 2025 09:19:04 -0400	[thread overview]
Message-ID: <540169d212d09dcc412ef86c127f6c8b74fa676f.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAGLnvc_eyLEasc4tKYnYp2c1M+YYRxaoXt2BmJ3kgAec6YTmzg@mail.gmail.com>

On Fri, 2025-03-21 at 15:13 +0800, lee joey wrote:
> Hi Lennart,
> 
> Lennart Poettering <mzxreary@0pointer.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


  parent reply	other threads:[~2025-03-21 13:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 12:02 Lennart Poettering
2025-03-20 14:52 ` Jarkko Sakkinen
2025-03-21  7:13 ` lee joey
2025-03-21  8:39   ` Lennart Poettering
2025-03-22 21:24     ` Jarkko Sakkinen
2025-03-21 13:19   ` James Bottomley [this message]
2025-07-03  1:40 ` Mimi Zohar
2025-07-03  7:18   ` Lennart Poettering
2025-07-03 11:23     ` Mimi Zohar
2025-07-03 13:04       ` Lennart Poettering
2025-07-03 23:56         ` Mimi Zohar
2025-07-04  7:34           ` Lennart Poettering
2025-07-08 20:52             ` Mimi Zohar
2025-07-04  1:30         ` GONG Ruiqi
2025-07-04  7:47           ` Lennart Poettering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=540169d212d09dcc412ef86c127f6c8b74fa676f.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=eric.snowberg@oracle.com \
    --cc=jarkko@kernel.org \
    --cc=jlee@suse.com \
    --cc=jmorris@namei.org \
    --cc=joeyli.kernel@gmail.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mzxreary@0pointer.de \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®