linux-kernel - Re: [PATCH 0/2] Secure Boot lock down

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: <CAHC9VhQ+4=J=nf2Yeb_QACVD4-d3_aUScpBAZhGyj7_+z+mBEw@mail.gmail.com>
Date: Thu, 24 Jul 2025 22:43:44 -0400
From: Paul Moore <paul@...l-moore.com>
To: Nicolas Bouchinet <nicolas.bouchinet@....cyber.gouv.fr>
Cc: Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>, Xiu Jianfeng <xiujianfeng@...wei.com>, 
	linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	Yue Haibing <yuehaibing@...wei.com>, Tanya Agarwal <tanyaagarwal25699@...il.com>, 
	Kees Cook <kees@...nel.org>, linux-efi@...r.kernel.org, 
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH 0/2] Secure Boot lock down

On Thu, Jul 24, 2025 at 8:59 AM Nicolas Bouchinet
<nicolas.bouchinet@....cyber.gouv.fr> wrote:
>
> Hi Hamza, thanks for your patch.
>
> Thanks, Paul, for the forward.
>
> Sorry for the delay, we took a bit of time to do some lore archaeology
> and discuss it with Xiu.
>
> As you might know, this has already been through debates in 2017 [1]. At
> that time, the decision was not to merge this behavior.
>
> Distros have indeed carried downstream patches reflecting this behavior
> for a long time and have been affected by vulnerabilities like
> CVE-2025-1272 [2], which is caused by the magic sprinkled in
> setup_arch().
>
> While your implementation looks cleaner to me. One of the points in
> previous debates was to have a Lockdown side Kconfig knob to enable or
> not this behavior. It would gate the registration of the Lockdown LSM to
> the security_lock_kernel_down() hook.
>
> However, what bothers me is that with this patch, if UEFI Secure Boot is
> activated and a user wants to disable Lockdown, they need to go through
> disabling Secure Boot. I'm really not fond of that. A user shouldn't
> have to be forced to disable security firmware settings because of a
> kernel feature.
>
> We thus might want to add a way to disable Lockdown through kernel
> cmdline.

One can enable/disable "normal" LSMs via the "lsm=" kernel command
line option, however, as Lockdown is an "early" LSM, it is enabled
prior to the command line option parsing in the kernel so that isn't
really an option unless we add some mechanism to later disable
Lockdown during the "normal" LSM initialization phase when the command
line options are available.  This would result in a window of time
during very early boot where Lockdown would be enabled, before being
disabled, but I have no idea how problematic that might be for users.

-- 
paul-moore.com