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", };