6.2.2 will NOT have lockdown patches
Hi all, due to regressions we saw with lockdown patches in Tumbleweed (esp. bsc#1209006), I decided to disable the lockdown patches for now. This will be merged with 6.2.2 (SR#1070329). You can use (the currently building) Kernel:stable too. Lockdown will be retried once in better shape. Or maybe secureboot will be buried in history at that time and we won't care ;). (I have blacklotus on my mind.) The current (might be extended later or at your request) conditions are: * external modules would work out of the box * the bug asking to enable lockdown would be visible to all sorry for all the trouble, -- js suse labs
Am 09.03.23 um 07:27 schrieb Jiri Slaby:
Hi all,
due to regressions we saw with lockdown patches in Tumbleweed (esp. bsc#1209006), I decided to disable the lockdown patches for now. This will be merged with 6.2.2 (SR#1070329). You can use (the currently building) Kernel:stable too.
Lockdown will be retried once in better shape. Or maybe secureboot will be buried in history at that time and we won't care ;). (I have blacklotus on my mind.)
The current (might be extended later or at your request) conditions are: * external modules would work out of the box * the bug asking to enable lockdown would be visible to all
sorry for all the trouble,
kernel-default-6.2.2-3.1.g4752516.x86_64 from Kernel:stable still has
cat /sys/kernel/security/lockdown none [integrity] confidentiality
Regards, Frank
Hi folks, First, thanks for Jiri's help! On Thu, Mar 09, 2023 at 07:27:14AM +0100, Jiri Slaby wrote:
Hi all,
due to regressions we saw with lockdown patches in Tumbleweed (esp. bsc#1209006), I decided to disable the lockdown patches for now. This will be merged with 6.2.2 (SR#1070329). You can use (the currently building) Kernel:stable too.
Lockdown will be retried once in better shape. Or maybe secureboot will be buried in history at that time and we won't care ;). (I have blacklotus on my mind.)
I have a open question and no answer: Do we want to lockdown Tumbleweed kernel? In the following articles, Linus Torvalds mentioned: Kernel lockdown locked out — for now https://lwn.net/Articles/751061/ https://lwn.net/Articles/751145/ Because I find it a *lot* more convincing to hear: "We'd like to just enable it all the time, but it's known to break some unusual hardware cases that we can't fix in software, and we wanted *some* way to disable it that requires explicit and verified user intervention to do that, and disabling secure boot is the easiest hack we could come up with". ------------------------------------------------------------------------- Finally the lockdown patchset be merged to kernel mainline after it removed the patch for linking lockdown with secure_boot. So, lockdown function doesn't have relation with secure boot in kernel mainline. Lockdown is lockdwn , secure boot is secure boot. Even if secure boot goes into history, lockdown function is still in kernel. Current Tumbleweed kernel is not lockdown. So anyone develops his application base on Tumbleweed who should awares that his application may not works with lockdowned kernel (means almost all big distros). Unless you enable lockdown yourself to develop/test your application. Please check the lockdown_reasons array in security/security.c in kernel source. [1] Why almost all big distros are enabled lockdown function by downstream patch for linking lockdown with secure boot? Because they (include SLE/Leap) send shim to shim-review projects for review then grabbing Microsoft signing. And we are afraid a non-lockdown kernenl to be a reason that causes our shim/key be revoked. The right to interpret is in the hands of Microsoft. The lockdown is a security function in kernel, we can choice do not enable it in Tumbleweed kernel. Then we have several approaches: - Still using Microsoft signed openSUSE shim (if they want to sign) We should aware that MS can choice to revoke or refuse signing. - Using openSUSE signed shim. User needs to enroll openSUSE key to UEFI db through firmware UI before install Tumbleweed. And openSUSE community will takes the risk when shim be found vulnerability then we need to revoke it by ourself. - Let's forgot secure boot and even forgot shim. We just disable secure boot before install Tumbleweed. Developers should aware that their application may not works on lockddown kernel, include SLE/Leap. Back to the question: Do we want to lockdown Tumbleweed kernel?
The current (might be extended later or at your request) conditions are: * external modules would work out of the box * the bug asking to enable lockdown would be visible to all
sorry for all the trouble,
Actually, it's my fault. I didn't port KEYS-Make-use-of-platform-keyring-for-module-signatu.patch patch to Tumbleweed kernel. We need this patch to allow .platform (db and mok) keyring be used to verify kernel module. Otherwise we will need shim v15.5 and later. But now we only have MS-signed shim 15.4 for Tumbleweed. Thanks a lot Joey Lee [1] The lockdown functions list in v6.2. It's growing. security/security.c const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { [LOCKDOWN_NONE] = "none", [LOCKDOWN_MODULE_SIGNATURE] = "unsigned module loading", [LOCKDOWN_DEV_MEM] = "/dev/mem,kmem,port", [LOCKDOWN_EFI_TEST] = "/dev/efi_test access", [LOCKDOWN_KEXEC] = "kexec of unsigned images", [LOCKDOWN_HIBERNATION] = "hibernation", [LOCKDOWN_PCI_ACCESS] = "direct PCI access", [LOCKDOWN_IOPORT] = "raw io port access", [LOCKDOWN_MSR] = "raw MSR access", [LOCKDOWN_ACPI_TABLES] = "modifying ACPI tables", [LOCKDOWN_DEVICE_TREE] = "modifying device tree contents", [LOCKDOWN_PCMCIA_CIS] = "direct PCMCIA CIS storage", [LOCKDOWN_TIOCSSERIAL] = "reconfiguration of serial port IO", [LOCKDOWN_MODULE_PARAMETERS] = "unsafe module parameters", [LOCKDOWN_MMIOTRACE] = "unsafe mmio", [LOCKDOWN_DEBUGFS] = "debugfs access", [LOCKDOWN_XMON_WR] = "xmon write access", [LOCKDOWN_BPF_WRITE_USER] = "use of bpf to write user RAM", [LOCKDOWN_DBG_WRITE_KERNEL] = "use of kgdb/kdb to write kernel RAM", [LOCKDOWN_RTAS_ERROR_INJECTION] = "RTAS error injection", [LOCKDOWN_INTEGRITY_MAX] = "integrity", [LOCKDOWN_KCORE] = "/proc/kcore access", [LOCKDOWN_KPROBES] = "use of kprobes", [LOCKDOWN_BPF_READ_KERNEL] = "use of bpf to read kernel RAM", [LOCKDOWN_DBG_READ_KERNEL] = "use of kgdb/kdb to read kernel RAM", [LOCKDOWN_PERF] = "unsafe use of perf", [LOCKDOWN_TRACEFS] = "use of tracefs", [LOCKDOWN_XMON_RW] = "xmon read and write access", [LOCKDOWN_XFRM_SECRET] = "xfrm SA secret", [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality", };
Hi Bruno, Sorry for my delay. On Fri, Mar 10, 2023 at 10:12:34AM -0000, Bruno Pitrus wrote:
Let's forgot secure boot and even forgot shim. I second this option — for people who want to use secure boot with their own keys through dracut, Microsoft's requirements are an impediment.
Do you mean uefi_secureboot_cert? Then user should enroll their certificate to UEFI db. We also need enable CONFIG_SYSTEM_EXTRA_CERTIFICATE in kernel for user put their own key to kernel to verify kernel module. Almost all shipped machines have secure boot enabled by default. If users know that they should disable secure boot through firmware switch before installing openSUSE Tumbleweed. And developers don't care the environment gap between Tumbleweed with Leap/SLE. Then maybe we can ship a shim-less Tumbleweed. No matter how, it will cause Tumbleweed difficult to use for most users. Regards Joey Lee
Yes i use uefi_secureboot_cert in /etc/dracut.conf.d/blah.conf I have no use for verification of kernel modules — i use full drive encryption on that computer, the secure boot is only for handling the stuff on EFI partition that cannot be encrypted.
Hi Joey, Is there a way we can have Secure Boot, kernel lockdown enabled, BUT still have the ability to generate our own key, compile and sign modules with that key, mokutil --import and enroll the key during reboot, and have the kernel load the modules signed with our key? If that is possible, then it sounds like that would resolve all the complaints from the users I have talked too. It would certainly work for my use case which involves compiling the vmware vmmon and vmnet kernel modules.
I didn't port KEYS-Make-use-of-platform-keyring-for-module- signatu.patch patch to Tumbleweed kernel. We need this patch >> to allow .platform (db and mok) keyring be used to verify kernel module. Otherwise we will need shim v15.5 and later. But now we only have MS-signed shim 15.4 for Tumbleweed.
If that patch had been ported, would that have provided what I asked in my first question? Thanks for your efforts with these issues! Joe
Joe Salmeri wrote:
Hi Joey, Is there a way we can have Secure Boot, kernel lockdown enabled, BUT still have the ability to generate our own key, compile and sign modules with that key, mokutil --import and enroll the key during reboot, and have the kernel load the modules signed with our key? If that is possible, then it sounds like that would resolve all the complaints from the users I have talked too. It would not resolve my complaints. I don't use shim for booting, and i have no idea how to integrate shim with systemd-boot.
(Anyway, kernel 6.2.2 works for me correctly)
Hi Joe, Sorry for my delay! On Fri, Mar 10, 2023 at 03:17:19PM -0000, Joe Salmeri wrote:
Hi Joey,
Is there a way we can have Secure Boot, kernel lockdown enabled, BUT still have the ability to generate our own key, compile and sign modules with that key, mokutil --import and enroll the key during reboot, and have the kernel load the modules signed with our key?
If that is possible, then it sounds like that would resolve all the complaints from the users I have talked too.
It would certainly work for my use case which involves compiling the vmware vmmon and vmnet kernel modules.
I didn't port KEYS-Make-use-of-platform-keyring-for-module- signatu.patch patch to Tumbleweed kernel. We need this patch >> to allow .platform (db and mok) keyring be used to verify kernel module. Otherwise we will need shim v15.5 and later. But now we only have MS-signed shim 15.4 for Tumbleweed.
If that patch had been ported, would that have provided what I asked in my first question?
Yes, we put a downstream patch KEYS-Make-use-of-platform-keyring-for-module-signatu.patch to SLE/Leap kernel then MOK can be used to verify kernel module. Actually almost all big distros included similar patch, except Tumbleweed. Currently it's still a gap between upstream kernel with distros. Kernel community is working on this: Newest patch set: [PATCH v5 0/6] Add CA enforcement keyring restrictions https://lore.kernel.org/lkml/20230302164652.83571-1-eric.snowberg@oracle.com... And some materials: keyrings, key usage, and trust models https://lore.kernel.org/all/20220928055900.GT4909@linux-l9pv.suse/t/#m3ce7e4... https://static.sched.com/hosted_files/lssna2022/18/LSS%202022%20trust%20and%... Regards Joey Lee
On Fri, Mar 24, 2023 at 06:01:36PM +0800, joeyli via openSUSE Factory wrote:
Hi Joe,
Sorry for my delay!
On Fri, Mar 10, 2023 at 03:17:19PM -0000, Joe Salmeri wrote:
Hi Joey,
Is there a way we can have Secure Boot, kernel lockdown enabled, BUT still have the ability to generate our own key, compile and sign modules with that key, mokutil --import and enroll the key during reboot, and have the kernel load the modules signed with our key?
If that is possible, then it sounds like that would resolve all the complaints from the users I have talked too.
It would certainly work for my use case which involves compiling the vmware vmmon and vmnet kernel modules.
I didn't port KEYS-Make-use-of-platform-keyring-for-module- signatu.patch patch to Tumbleweed kernel. We need this patch >> to allow .platform (db and mok) keyring be used to verify kernel module. Otherwise we will need shim v15.5 and later. But now we only have MS-signed shim 15.4 for Tumbleweed.
If that patch had been ported, would that have provided what I asked in my first question?
Yes, we put a downstream patch KEYS-Make-use-of-platform-keyring-for-module-signatu.patch to SLE/Leap kernel then MOK can be used to verify kernel module. Actually almost all big distros included similar patch, except Tumbleweed.
Currently it's still a gap between upstream kernel with distros. Kernel community is working on this:
Newest patch set: [PATCH v5 0/6] Add CA enforcement keyring restrictions https://lore.kernel.org/lkml/20230302164652.83571-1-eric.snowberg@oracle.com...
Which is completely irrelevant for usability of MOK keys in the distribution if not outright harmful. So long as upstream does not implement key management that is usable in a general purpose distribution we do need downstream patches, and there is no indication that upstream is heading in that direction. Thanks Michal
Hi Joey, On thing I don't understand about when lockdown was enabled. According to this https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html The Kernel Lockdown feature is enabled by CONFIG_SECURITY_LOCKDOWN_LSM. grep CONFIG_SECURITY_LOCKDOWN /usr/lib/modules/*/config Returns /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y So on this TW system both were set to 'y' in the 6.1.8 and 6.2.1 kernels. Since the 6.1.8 kernel allowed the vmware modules ( which I didn't sign ) to load, it would appear that this kernel lockdown also changes some other configuration too. What else was done when the kernel lockdown was enabled? Joe
* Joe Salmeri
Hi Joey,
On thing I don't understand about when lockdown was enabled.
According to this
https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
The Kernel Lockdown feature is enabled by CONFIG_SECURITY_LOCKDOWN_LSM.
grep CONFIG_SECURITY_LOCKDOWN /usr/lib/modules/*/config
Returns
/usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
So on this TW system both were set to 'y' in the 6.1.8 and 6.2.1 kernels.
Since the 6.1.8 kernel allowed the vmware modules ( which I didn't sign ) to load, it would appear that this kernel lockdown also changes some other configuration too.
What else was done when the kernel lockdown was enabled?
fwiw: /usr/lib/modules/6.1.10-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.10-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.1.12-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.12-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.1.4-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.4-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.1.6-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.6-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.1.7-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.7-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.2.0-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.2.0-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Hi Patrick, Right, I only listed the 2 kernels on my test machine, but on my main machine ( which doesn't have 6.2.1 yet ) ALL kernels installed have both set to 'y' too. So the question remains, what else was done to enable lockdown since those settings were both set to 'y' for a while now and none of the older kernels had these issues. I would have expected the linked article/docs to have answered that but it didn't. Joe
Hi Joe, On Fri, Mar 10, 2023 at 07:16:38PM -0000, Joe Salmeri wrote:
Hi Joey,
On thing I don't understand about when lockdown was enabled.
According to this
https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html
The Kernel Lockdown feature is enabled by CONFIG_SECURITY_LOCKDOWN_LSM.
grep CONFIG_SECURITY_LOCKDOWN /usr/lib/modules/*/config
Returns
/usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.1.8-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM=y /usr/lib/modules/6.2.1-1-default/config:CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
So on this TW system both were set to 'y' in the 6.1.8 and 6.2.1 kernels.
Since the 6.1.8 kernel allowed the vmware modules ( which I didn't sign ) to load, it would appear that this kernel lockdown also changes some other configuration too.
What else was done when the kernel lockdown was enabled?
We set the following kernel config in TW/Leap/SLE kernels: CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set So, the default lockdown mode is NONE which means the lockdown is not active by default. The point is that we applied two downstream patches: patches.suse/0003-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mode.patch patches.suse/0004-efi-Lock-down-the-kernel-at-the-integrity-level-if-b.patch The above patches link secure boot with lockdown function, and also set the default lockdown mode to integrity mode. Just like mok for modsign, almost all big distros are applied similar patches. Here is also the gap between maineline kernel with SUSE kernel. Kernel upstream think that the lockdown function is useful with or without secure boot. But from distros' view point, direct lockdown kernel will causses many userland application are blocked. So we need a switch to turn on/off it. Linking to EFI secure boot is a approach, because only machine owner can turn off secure boot by physical accessing. In terms of roles, it is stricter than the system admin. Another reason is almost all big distros' shim be signed by Microsoft. We don't want Microsoft revoke our shim or key when kernel is not lockdown. Regards Joey Lee
participants (7)
-
Bruno Pitrus -
Frank Krüger -
Jiri Slaby -
Joe Salmeri -
joeyli -
Michal Suchánek -
Patrick Shanahan