* [GIT PULL] Kernel lockdown for secure boot @ 2018-03-30 23:29 David Howells 2018-03-31 0:46 ` James Morris ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: David Howells @ 2018-03-30 23:29 UTC (permalink / raw) To: jmorris Cc: dhowells, gnomes, linux-efi, mjg59, gregkh, linux-kernel, jforbes, linux-man, jlee, linux-security-module Date: Thu, 26 Oct 2017 17:37:38 +0100 Hi James, Can you pull this patchset into security/next please? It has been in linux-next since the beginning of March. It adds kernel lockdown support for EFI secure boot. There's a manual page (kernel_lockdown.7) associated with this: .\" .\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved. .\" Written by David Howells (dhowells@redhat.com) .\" .\" %%%LICENSE_START(GPLv2+_SW_ONEPARA) .\" This program is free software; you can redistribute it and/or .\" modify it under the terms of the GNU General Public License .\" as published by the Free Software Foundation; either version .\" 2 of the License, or (at your option) any later version. .\" %%%LICENSE_END .\" .TH "KERNEL LOCKDOWN" 7 2017-10-05 Linux "Linux Programmer's Manual" .SH NAME Kernel Lockdown \- Kernel image access prevention feature .SH DESCRIPTION The Kernel Lockdown feature is designed to prevent both direct and indirect access to a running kernel image, attempting to protect against unauthorised modification of the kernel image and to prevent access to security and cryptographic data located in kernel memory, whilst still permitting driver modules to be loaded. .P Lockdown is typically enabled during boot and may be terminated, if configured, by typing a special key combination on a directly attached physical keyboard. .P If a prohibited or restricted feature is accessed or used, the kernel will emit a message that looks like: .P .RS Lockdown: X: Y is restricted, see man kernel_lockdown.7 .RE .P where X indicates the process name and Y indicates what is restricted. .P On an EFI-enabled x86 or arm64 machine, lockdown will be automatically enabled if the system boots in EFI Secure Boot mode. .P If the kernel is appropriately configured, lockdown may be lifted by typing the appropriate sequence on a directly attached physical keyboard. For x86 machines, this is .IR SysRq+x . .\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" .SH COVERAGE When lockdown is in effect, a number of features are disabled or have their use restricted. This includes special device files and kernel services that allow direct access of the kernel image: .P .RS /dev/mem .br /dev/kmem .br /dev/kcore .br /dev/ioports .br BPF .br kprobes .RE .P and the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image: .P .RS The use of module parameters that directly specify hardware parameters to drivers through the kernel command line or when loading a module. .P The use of direct PCI BAR access. .P The use of the ioperm and iopl instructions on x86. .P The use of the KD*IO console ioctls. .P The use of the TIOCSSERIAL serial ioctl. .P The alteration of MSR registers on x86. .P The replacement of the PCMCIA CIS. .P The overriding of ACPI tables. .P The use of ACPI error injection. .P The specification of the ACPI RDSP address. .P The use of ACPI custom methods. .RE .P Certain facilities are restricted: .P .RS Only validly signed modules may be loaded (waived if the module file being loaded is vouched for by IMA appraisal). .P Only validly signed binaries may be kexec'd (waived if the binary image file to be executed is vouched for by IMA appraisal). .P Unencrypted hibernation/suspend to swap are disallowed as the kernel image is saved to a medium that can then be accessed. .P Use of debugfs is not permitted as this allows a whole range of actions including direct configuration of, access to and driving of hardware. .P IMA requires the addition of the "secure_boot" rules to the policy, whether or not they are specified on the command line, for both the builtin and custom policies in secure boot lockdown mode. .RE David --- The following changes since commit 6f70eb2b00eb416146247c65003d31f4df983ce0: Merge branch 'idr-2018-02-06' of git://git.infradead.org/users/willy/linux-dax (2018-02-26 13:22:45 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/lockdown-20180330 for you to fetch changes up to 89bcd5b02f125335f74289c5f4ae03e9b893ab7f: lockdown: Print current->comm in restriction messages (2018-02-28 14:43:03 +0000) ---------------------------------------------------------------- Kernel lockdown ---------------------------------------------------------------- Dave Young (1): Copy secure_boot flag in boot params across kexec reboot David Howells (15): Add the ability to lock down access to the running kernel image Enforce module signatures if the kernel is locked down scsi: Lock down the eata driver Prohibit PCMCIA CIS storage when the kernel is locked down Lock down TIOCSSERIAL Lock down module params that specify hardware parameters (eg. ioport) x86/mmiotrace: Lock down the testmmiotrace module Lock down /proc/kcore Lock down kprobes bpf: Restrict kernel image access functions when the kernel is locked down Lock down perf debugfs: Restrict debugfs when the kernel is locked down efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode efi: Lock down the kernel if booted in secure boot mode lockdown: Print current->comm in restriction messages Jiri Bohac (2): kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE kexec_file: Restrict at runtime if the kernel is locked down Josh Boyer (2): hibernate: Disable when the kernel is locked down acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down Kyle McMartin (1): Add a SysRq option to lift kernel lockdown Linn Crosetto (2): acpi: Disable ACPI table override if the kernel is locked down acpi: Disable APEI error injection if the kernel is locked down Matthew Garrett (7): Restrict /dev/{mem,kmem,port} when the kernel is locked down kexec_load: Disable at runtime if the kernel is locked down uswsusp: Disable when the kernel is locked down PCI: Lock down BAR access when the kernel is locked down x86: Lock down IO port access when the kernel is locked down x86/msr: Restrict MSR access when the kernel is locked down ACPI: Limit access to custom_method when the kernel is locked down Mimi Zohar (1): ima: require secure_boot rules in lockdown mode arch/x86/Kconfig | 20 ++++-- arch/x86/include/asm/setup.h | 2 + arch/x86/kernel/ioport.c | 6 +- arch/x86/kernel/kexec-bzimage64.c | 1 + arch/x86/kernel/machine_kexec_64.c | 2 +- arch/x86/kernel/msr.c | 10 +++ arch/x86/kernel/setup.c | 18 ++---- arch/x86/mm/testmmiotrace.c | 3 + crypto/asymmetric_keys/verify_pefile.c | 4 +- drivers/acpi/apei/einj.c | 3 + drivers/acpi/custom_method.c | 3 + drivers/acpi/osl.c | 2 +- drivers/acpi/tables.c | 5 ++ drivers/char/mem.c | 2 + drivers/firmware/efi/Makefile | 1 + drivers/firmware/efi/secureboot.c | 38 ++++++++++++ drivers/input/misc/uinput.c | 1 + drivers/pci/pci-sysfs.c | 9 +++ drivers/pci/proc.c | 9 ++- drivers/pci/syscall.c | 3 +- drivers/pcmcia/cistpl.c | 3 + drivers/scsi/eata.c | 5 +- drivers/tty/serial/serial_core.c | 6 ++ drivers/tty/sysrq.c | 19 ++++-- fs/debugfs/file.c | 28 +++++++++ fs/debugfs/inode.c | 30 ++++++++- fs/proc/kcore.c | 2 + include/linux/efi.h | 16 +++-- include/linux/input.h | 5 ++ include/linux/kernel.h | 17 ++++++ include/linux/kexec.h | 4 +- include/linux/security.h | 8 +++ include/linux/sysrq.h | 8 ++- kernel/bpf/syscall.c | 3 + kernel/debug/kdb/kdb_main.c | 2 +- kernel/events/core.c | 5 ++ kernel/kexec.c | 7 +++ kernel/kexec_file.c | 56 ++++++++++++++--- kernel/kprobes.c | 3 + kernel/module.c | 56 +++++++++++++---- kernel/params.c | 26 ++++++-- kernel/power/hibernate.c | 2 +- kernel/power/user.c | 3 + security/Kconfig | 32 ++++++++++ security/Makefile | 3 + security/integrity/ima/ima_policy.c | 39 +++++++++--- security/lock_down.c | 108 +++++++++++++++++++++++++++++++++ 47 files changed, 557 insertions(+), 81 deletions(-) create mode 100644 drivers/firmware/efi/secureboot.c create mode 100644 security/lock_down.c ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells @ 2018-03-31 0:46 ` James Morris 2018-04-03 0:37 ` Andy Lutomirski 2018-04-03 7:06 ` David Howells 2018-03-31 10:20 ` David Howells 2018-11-21 12:05 ` [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series Vasily Gorbik 2 siblings, 2 replies; 116+ messages in thread From: James Morris @ 2018-03-31 0:46 UTC (permalink / raw) To: David Howells Cc: gnomes, linux-efi, mjg59, gregkh, linux-kernel, jforbes, linux-man, jlee, linux-security-module On Sat, 31 Mar 2018, David Howells wrote: > Date: Thu, 26 Oct 2017 17:37:38 +0100 > > Hi James, > > Can you pull this patchset into security/next please? It has been in > linux-next since the beginning of March. > > It adds kernel lockdown support for EFI secure boot. Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-lockdown and next-testing Are there any known coverage gaps now? -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-03-31 0:46 ` James Morris @ 2018-04-03 0:37 ` Andy Lutomirski 2018-04-03 0:59 ` Kees Cook 2018-04-03 7:06 ` David Howells 1 sibling, 1 reply; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 0:37 UTC (permalink / raw) To: James Morris, David Howells Cc: gnomes, Linus Torvalds, mjg59, gregkh, linux-kernel, jforbes, linux-man, jlee, linux-security-module, Linux API, Kees Cook On 03/30/2018 05:46 PM, James Morris wrote: > On Sat, 31 Mar 2018, David Howells wrote: > >> Date: Thu, 26 Oct 2017 17:37:38 +0100 >> >> Hi James, >> >> Can you pull this patchset into security/next please? It has been in >> linux-next since the beginning of March. >> >> It adds kernel lockdown support for EFI secure boot. > > Applied to > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git > next-lockdown and next-testing > > Are there any known coverage gaps now? > > > This is an attempt at a review. I'm replying here because I can't find the actual relevant patch emails. Cover letter: > Here's a set of patches to institute a "locked-down mode" in the > kernel and to trigger that mode if the kernel is booted in secure-boot > mode or through the command line. I think this is seriously problematic in that it's not well defined. It sounds like "locked-down mode" means "make me feel good about something". For the rest of this review, I'm going to pretend that you actually want two features: "try-prevent-root-from-corrupting-the-kernel" and "try-to-prevent-root-from-reading-kernel-memory". Also, there should be a justification that allows normal people (i.e. those who are not involved in the UEFI signing process) to understand *why* this should have anything to do with UEFI. I can very easily see why it would make sense for a UEFI authenticated variable to tell the kernel to enable one or both of these modes or for there to be an authenticated mechanism for the bootloader to tell the kernel to enable it. I do *not* see why the mere act of using Secure Boot should have this effect. In particular, UEFI Secure Boot should *not* enable "try-to-prevent-root-from-reading-kernel-memory", which means that, unless you actually implement the split, you should drop a bunch of the patches. In fact, I think the kernel should try to get away from the idea that UEFI Secure Boot should imply annoying restrictions. It's really annoying and it's never been clear to me that it has a benefit. "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should probably split into one restriction for read and one for write. "Lock down /proc/kcore": should only apply to "try-to-prevent-root-from-reading-kernel-memory" "Lock down kprobes": ditto "bpf: Restrict kernel image access functions when the kernel is locked down": This patch just sucks in general. At the very least, it should only apply to "bpf: Restrict kernel image access functions when the kernel is locked down". But you should probably just force all eBPF users through the unprivileged path when locked down instead, since eBPF is really quite useful even with the stricter verification mode. "Lock down perf": how about preventing using perf on the kernel when "try-to-prevent-root-from-reading-kernel-memory" is set and not restricting it otherwise? "debugfs: Restrict debugfs when the kernel is locked down": The logic is IMO nutty. Why the 0444 restriction? I see no reason that reading a 0644 file should be treated any differently from reading a 0444 file. Regardless, I think you should prevent writing or reading depending on lockdown mode and add an API so that individual debugfs files can override this. "efi: Lock down the kernel if booted in secure boot mode": you have a stray change in fs/debugfs/inode.c in here. Also, as above, I really dislike this patch. "lockdown: Print current->comm in restriction messages": Shouldn't this be folded in with whatever patch added that code in the first place? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 0:37 ` Andy Lutomirski @ 2018-04-03 0:59 ` Kees Cook 2018-04-03 1:47 ` Andy Lutomirski 0 siblings, 1 reply; 116+ messages in thread From: Kees Cook @ 2018-04-03 0:59 UTC (permalink / raw) To: Andy Lutomirski Cc: James Morris, David Howells, Alan Cox, Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli, linux-security-module, Linux API On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski <luto@kernel.org> wrote: > On 03/30/2018 05:46 PM, James Morris wrote: >> >> On Sat, 31 Mar 2018, David Howells wrote: >> >>> Date: Thu, 26 Oct 2017 17:37:38 +0100 >>> >>> Hi James, >>> >>> Can you pull this patchset into security/next please? It has been in >>> linux-next since the beginning of March. >>> >>> It adds kernel lockdown support for EFI secure boot. >> >> >> Applied to >> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git >> next-lockdown and next-testing >> >> Are there any known coverage gaps now? >> >> >> > > This is an attempt at a review. I'm replying here because I can't find the > actual relevant patch emails. > > Cover letter: > >> Here's a set of patches to institute a "locked-down mode" in the >> kernel and to trigger that mode if the kernel is booted in secure-boot > >> mode or through the command line. > > I think this is seriously problematic in that it's not well defined. It > sounds like "locked-down mode" means "make me feel good about something". Naming of this feature has been multi-year bikeshedding, so if we could just leave the name, that'd be nice. > For the rest of this review, I'm going to pretend that you actually want two > features: "try-prevent-root-from-corrupting-the-kernel" and > "try-to-prevent-root-from-reading-kernel-memory". That is how I view it, yes. It's about creating a bright line between uid-0 and ring-0. The most powerful of these distinctions was made long ago with signed modules. It hasn't been enough, though, since there have been many ways for uid-0 to read or write kernel memory. My expectation for this was to reasonably fill all the remaining gaps. > Also, there should be a justification that allows normal people (i.e. those > who are not involved in the UEFI signing process) to understand *why* this > should have anything to do with UEFI. I can very easily see why it would > make sense for a UEFI authenticated variable to tell the kernel to enable > one or both of these modes or for there to be an authenticated mechanism for > the bootloader to tell the kernel to enable it. I do *not* see why the mere > act of using Secure Boot should have this effect. > > In particular, UEFI Secure Boot should *not* enable > "try-to-prevent-root-from-reading-kernel-memory", which means that, unless > you actually implement the split, you should drop a bunch of the patches. > > In fact, I think the kernel should try to get away from the idea that UEFI > Secure Boot should imply annoying restrictions. It's really annoying and > it's never been clear to me that it has a benefit. FWIW, I've never been a fan of this being UEFI-centric: more than Secure Boot needs this. For example, Chrome OS's static root of trust and boot firmware isn't UEFI, but it wants this feature enabled. Chrome OS would set it on the command line, since the command line is part of the signed boot image along with the kernel, etc. > "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should > probably split into one restriction for read and one for write. I think splitting read and write is only useful if there is a use-case for only blocking one of them. I struggle to imagine allowing write and blocking read, so really it's the case of wanting to allow read and disallow write. Is there actually a use-case for this? In all the "locked down" cases I've seen, both are desired. -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 0:59 ` Kees Cook @ 2018-04-03 1:47 ` Andy Lutomirski 0 siblings, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 1:47 UTC (permalink / raw) To: Kees Cook Cc: Andy Lutomirski, James Morris, David Howells, Alan Cox, Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli, linux-security-module, Linux API > On Apr 2, 2018, at 5:59 PM, Kees Cook <keescook@chromium.org> wrote: > >> On Mon, Apr 2, 2018 at 5:37 PM, Andy Lutomirski <luto@kernel.org> wrote: >>> On 03/30/2018 05:46 PM, James Morris wrote: >>> >>>> On Sat, 31 Mar 2018, David Howells wrote: >>>> >>>> Date: Thu, 26 Oct 2017 17:37:38 +0100 >>>> >>>> Hi James, >>>> >>>> Can you pull this patchset into security/next please? It has been in >>>> linux-next since the beginning of March. >>>> >>>> It adds kernel lockdown support for EFI secure boot. >>> >>> >>> Applied to >>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git >>> next-lockdown and next-testing >>> >>> Are there any known coverage gaps now? >>> >>> >>> >> >> This is an attempt at a review. I'm replying here because I can't find the >> actual relevant patch emails. >> >> Cover letter: >> >>> Here's a set of patches to institute a "locked-down mode" in the >>> kernel and to trigger that mode if the kernel is booted in secure-boot > >>> mode or through the command line. >> >> I think this is seriously problematic in that it's not well defined. It >> sounds like "locked-down mode" means "make me feel good about something". > > Naming of this feature has been multi-year bikeshedding, so if we > could just leave the name, that'd be nice. Fair enough. How about enum kernel_lockdown_level with three modes? > > >> "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should >> probably split into one restriction for read and one for write. > > I think splitting read and write is only useful if there is a use-case > for only blocking one of them. I struggle to imagine allowing write > and blocking read, so really it's the case of wanting to allow read > and disallow write. Is there actually a use-case for this? In all the > "locked down" cases I've seen, both are desired. > Let’s suppose for the sake of argument that UEFI really has a good reason to block writes. Blocking reads (kprobes, perf, etc) sounds extremely annoying, especially if running a stock distro, and I’d much rather not do it unless there’s a specific use case that needs it. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-03-31 0:46 ` James Morris 2018-04-03 0:37 ` Andy Lutomirski @ 2018-04-03 7:06 ` David Howells 2018-04-03 15:11 ` Andy Lutomirski 1 sibling, 1 reply; 116+ messages in thread From: David Howells @ 2018-04-03 7:06 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, James Morris, gnomes, Linus Torvalds, mjg59, gregkh, linux-kernel, jforbes, linux-man, jlee, linux-security-module, Linux API, Kees Cook Andy Lutomirski <luto@kernel.org> wrote: > This is an attempt at a review. I'm replying here because I can't find the > actual relevant patch emails. This was the latest post: https://lkml.org/lkml/2017/11/9/660 and they were posted multiple times before that, plus distributions, such as Fedora, have been carrying them for a long while. > For the rest of this review, I'm going to pretend that you actually want two > features: "try-prevent-root-from-corrupting-the-kernel" and > "try-to-prevent-root-from-reading-kernel-memory". It theoretically boils down into those two, but the line is blurrier than you think. Further, some of the vectors that can be used to do one can potentially do the other also and it starts getting to be a lot of extra work to distinguish the two. > I do *not* see why the mere act of using Secure Boot should have this > effect. To be able to pass secure boot mode over kexec, you have to make sure that the kernel image doesn't get corrupted, lest someone blacklist your signing key in the bootloader. > In particular, UEFI Secure Boot should *not* enable > "try-to-prevent-root-from-reading-kernel-memory", which means that, unless > you actually implement the split, you should drop a bunch of the patches. Yes it should. If someone can read your kernel image, they can steal the crypto keys you use to encrypt your filesystem. > "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should > probably split into one restriction for read and one for write. Not so for /dev/port. Read & Write here are _not_ the same as Read & Write on, say, /dev/mem. In fact, if /dev/mem gives you access to mmio ports, then the same applies there. Btw, Fedora hasn't even provided /dev/kmem for a while. > "bpf: Restrict kernel image access functions when the kernel is locked down": > This patch just sucks in general. Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since it gives you unrestricted access to the kernel. > "debugfs: Restrict debugfs when the kernel is locked down": The logic is IMO > nutty. Why the 0444 restriction? I see no reason that reading a 0644 file > should be treated any differently from reading a 0444 file. Yes. IMO it should be locked down entirely. However, it's been abused and there are things in there that are apparently needed (ie. it's not debugging-only now); unfortunately, it *also* contains files that directly map hardware. > "efi: Lock down the kernel if booted in secure boot mode": you have a stray > change in fs/debugfs/inode.c in here. Good catch, thanks. > Also, as above, I really dislike this patch. You dislike everything, but you didn't say so any of the times these patches were posted... > "lockdown: Print current->comm in restriction messages": Shouldn't this be > folded in with whatever patch added that code in the first place? Perhaps, but at the time I added it, I didn't want to go back and change the existing patches again. If I have to do so, I'll fold it in then. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 7:06 ` David Howells @ 2018-04-03 15:11 ` Andy Lutomirski 2018-04-03 15:41 ` Alexei Starovoitov 2018-04-03 16:29 ` Matthew Garrett 0 siblings, 2 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 15:11 UTC (permalink / raw) To: David Howells, Ard Biesheuvel Cc: Andy Lutomirski, James Morris, One Thousand Gnomes, Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi [re-added cc's, I think. Sorry, I think I failed to use the gmane gateway correctly there.] On Tue, Apr 3, 2018 at 12:06 AM, David Howells <dhowells@redhat.com> wrote: > Andy Lutomirski <luto@kernel.org> wrote: > >> This is an attempt at a review. I'm replying here because I can't find the >> actual relevant patch emails. > > This was the latest post: > > https://lkml.org/lkml/2017/11/9/660 > > and they were posted multiple times before that, plus distributions, such as > Fedora, have been carrying them for a long while. > >> For the rest of this review, I'm going to pretend that you actually want two >> features: "try-prevent-root-from-corrupting-the-kernel" and >> "try-to-prevent-root-from-reading-kernel-memory". > > It theoretically boils down into those two, but the line is blurrier than you > think. > > Further, some of the vectors that can be used to do one can potentially do the > other also and it starts getting to be a lot of extra work to distinguish the > two. > >> I do *not* see why the mere act of using Secure Boot should have this >> effect. > > To be able to pass secure boot mode over kexec, you have to make sure that the > kernel image doesn't get corrupted, lest someone blacklist your signing key in > the bootloader. Can you explain that much more clearly? I'm asking why booting via UEFI Secure Boot should enable lockdown, and I don't see what this has to do with kexec. And "someone blacklist[ing] your key in the bootloader" sounds like a political issue, not a technical issue. What is the actual purpose of these patches? > >> In particular, UEFI Secure Boot should *not* enable >> "try-to-prevent-root-from-reading-kernel-memory", which means that, unless >> you actually implement the split, you should drop a bunch of the patches. > > Yes it should. If someone can read your kernel image, they can steal the > crypto keys you use to encrypt your filesystem. Can you please explain the actual attack that is avoided by doing this? Suppose I'm a bad guy attacking someone's laptop. If I just have normal uid!=0 access, then these patches have no effect. Instead, we're talking about an attacker who is somehow able to become global root and bypass all LSM restrictions but has not gained kernel code execution. It is indeed the case that your patches make it harder to simply read the dm-crypt encryption key out of main memory. But root can attack the disk encryption in many other ways. They can persistently compromise the machine by adding services or user accounts or intentionally misconfiguring something. They can directly read the entire contents of the disk. They can modify the initrd so that the next time the machine reboots and the user types the password, the attacker gets the key (unless the TPM is involved, but getting *that* right on a standard distro is difficult or impossible). And I'm not even sure why an attacker who manages to become root wants your disk encryption key. That key is worth nothing unless the attacker makes its attack persistent, but, if the attacker can install a persistent user-level backdoor, then they can read the cleartext off your disk just as easily as they can read the ciphertext. > >> "Restrict /dev/{mem,kmem,port} when the kernel is locked down": this should >> probably split into one restriction for read and one for write. > > Not so for /dev/port. Read & Write here are _not_ the same as Read & Write > on, say, /dev/mem. In fact, if /dev/mem gives you access to mmio ports, then > the same applies there. Btw, Fedora hasn't even provided /dev/kmem for a > while. Then split /dev/mem and turn off /dev/port for all locked-down modes. > >> "bpf: Restrict kernel image access functions when the kernel is locked down": >> This patch just sucks in general. > > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since > it gives you unrestricted access to the kernel. bpf, in certain contexts, gives you unrestricted access to *reading* kernel memory. bpf should, under no circumstances, let you write to the kernel unless you're using fault injection or similar. I'm surprised that Alexei acked this patch. If something like XDP or bpfilter starts becoming widely used, this patch will require a lot of reworking to avoid breaking standard distros. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 15:11 ` Andy Lutomirski @ 2018-04-03 15:41 ` Alexei Starovoitov 2018-04-03 16:26 ` Andy Lutomirski 2018-04-03 16:29 ` Matthew Garrett 1 sibling, 1 reply; 116+ messages in thread From: Alexei Starovoitov @ 2018-04-03 15:41 UTC (permalink / raw) To: Andy Lutomirski Cc: David Howells, Ard Biesheuvel, James Morris, One Thousand Gnomes, Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: > > > >> "bpf: Restrict kernel image access functions when the kernel is locked down": > >> This patch just sucks in general. > > > > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since > > it gives you unrestricted access to the kernel. > > bpf, in certain contexts, gives you unrestricted access to *reading* > kernel memory. bpf should, under no circumstances, let you write to > the kernel unless you're using fault injection or similar. > > I'm surprised that Alexei acked this patch. If something like XDP or > bpfilter starts becoming widely used, this patch will require a lot of > reworking to avoid breaking standard distros. my understanding was that this lockdown set attemps to disallow _reads_ of kernel memory from anything, so first version of patch was adding run-time checks for bpf_probe_read() which is no-go and without this helper the bpf for tracing is losing a lot of its power, so the easiest is to disable it all. I think lockdown suppose to disable xdp, bpfilter, nflog, raw sockets + pcap too otherwise even cap_net_admin can see traffic coming into host. Similarly kprobe, perf_event, ftrace should be off as well? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 15:41 ` Alexei Starovoitov @ 2018-04-03 16:26 ` Andy Lutomirski 0 siblings, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 16:26 UTC (permalink / raw) To: Alexei Starovoitov Cc: Andy Lutomirski, David Howells, Ard Biesheuvel, James Morris, One Thousand Gnomes, Linus Torvalds, Matthew Garrett, Greg KH, LKML, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 8:41 AM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > On Tue, Apr 03, 2018 at 08:11:07AM -0700, Andy Lutomirski wrote: >> > >> >> "bpf: Restrict kernel image access functions when the kernel is locked down": >> >> This patch just sucks in general. >> > >> > Yes - but that's what Alexei Starovoitov specified. bpf kind of sucks since >> > it gives you unrestricted access to the kernel. >> >> bpf, in certain contexts, gives you unrestricted access to *reading* >> kernel memory. bpf should, under no circumstances, let you write to >> the kernel unless you're using fault injection or similar. >> >> I'm surprised that Alexei acked this patch. If something like XDP or >> bpfilter starts becoming widely used, this patch will require a lot of >> reworking to avoid breaking standard distros. > > my understanding was that this lockdown set attemps to disallow _reads_ > of kernel memory from anything, so first version of patch was adding > run-time checks for bpf_probe_read() which is no-go > and without this helper the bpf for tracing is losing a lot of its power, > so the easiest is to disable it all. Fair enough. > I think lockdown suppose to disable xdp, bpfilter, nflog, raw sockets + pcap too > otherwise even cap_net_admin can see traffic coming into host. > Similarly kprobe, perf_event, ftrace should be off as well? > I'm reasonably sure that lockdown is not intended to be this far reaching. cap_net_admin can see traffic coming into the host, and I don't think lockdown is intended to change that. David, I think this is exactly why you need to define what "lockdown" means. As it stands, the best argument I've seen involves "blacklisting", but that's a political thing and almost no one involved has any ability to evaluate it. Right now there's a series of patches that check for "lockdown" and seem to disable things that make someone uncomfortable. That's not a good way to design a security feature. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 15:11 ` Andy Lutomirski 2018-04-03 15:41 ` Alexei Starovoitov @ 2018-04-03 16:29 ` Matthew Garrett 2018-04-03 16:45 ` Andy Lutomirski ` (2 more replies) 1 sibling, 3 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 16:29 UTC (permalink / raw) To: luto Cc: David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: > Can you explain that much more clearly? I'm asking why booting via > UEFI Secure Boot should enable lockdown, and I don't see what this has > to do with kexec. And "someone blacklist[ing] your key in the > bootloader" sounds like a political issue, not a technical issue. A kernel that allows users arbitrary access to ring 0 is just an overfeatured bootloader. Why would you want secure boot in that case? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 16:29 ` Matthew Garrett @ 2018-04-03 16:45 ` Andy Lutomirski 2018-04-03 18:45 ` Kees Cook 2018-04-03 19:29 ` Matthew Garrett 2018-04-03 17:16 ` David Howells 2018-04-03 20:53 ` Linus Torvalds 2 siblings, 2 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 16:45 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: >> Can you explain that much more clearly? I'm asking why booting via >> UEFI Secure Boot should enable lockdown, and I don't see what this has >> to do with kexec. And "someone blacklist[ing] your key in the >> bootloader" sounds like a political issue, not a technical issue. > > A kernel that allows users arbitrary access to ring 0 is just an > overfeatured bootloader. Why would you want secure boot in that case? To get a chain of trust. I can provision a system with some public keys, stored in UEFI authenticated variables, such that the system will only boot a signed image. That signed image, can, in turn, load a signed (or hashed or otherwise verfified) kernel and a verified initramfs. The initramfs can run a full system from a verified (using dm-verity or similar) filesystem, for example. Now it's very hard to persistently attack this system. Chromium OS does something very much like this, except that it doesn't use UEFI as far as I know. So does iOS, and so do some Android versions. None of this requires lockdown, or even a separation between usermode and kernelmode, to work correctly. One could even do this on an MMU-less system if one really cared to. More usefully, someone probably has done this using a unikernel. If I had to guess at a motivation that makes this patchset work, it would be that there is an uneasy truce between Microsoft and the various vendors of signed Linux bootloaders. That truce could conceivably require that the signed bootloaders not knowingly ship a system that allows a non-physically-present user to chainload Windows. If so, the patchset should say that loud and clear in its description and the parts that block bpf should go away. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 16:45 ` Andy Lutomirski @ 2018-04-03 18:45 ` Kees Cook 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:29 ` Matthew Garrett 1 sibling, 1 reply; 116+ messages in thread From: Kees Cook @ 2018-04-03 18:45 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, linux-efi On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: >> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: >>> Can you explain that much more clearly? I'm asking why booting via >>> UEFI Secure Boot should enable lockdown, and I don't see what this has >>> to do with kexec. And "someone blacklist[ing] your key in the >>> bootloader" sounds like a political issue, not a technical issue. >> >> A kernel that allows users arbitrary access to ring 0 is just an >> overfeatured bootloader. Why would you want secure boot in that case? > > To get a chain of trust. I can provision a system with some public > keys, stored in UEFI authenticated variables, such that the system > will only boot a signed image. That signed image, can, in turn, load > a signed (or hashed or otherwise verfified) kernel and a verified > initramfs. The initramfs can run a full system from a verified (using > dm-verity or similar) filesystem, for example. Now it's very hard to > persistently attack this system. Chromium OS does something very much > like this, except that it doesn't use UEFI as far as I know. So does > iOS, and so do some Android versions. Correct, Chrome OS does not use UEFI, and we still want this patch series, as it plugs all the known "intentional" escalation paths from uid-0 to ring-0. Happily, that means all the politics around the UEFI and Secure Boot case can be ignored, because those issues are specific to Secure Boot, not the lockdown series. (They are _related_, sure, but lockdown isn't only about Secure Boot -- it's just that SB is one of the widely deployed implementations of this kind of trust-chain-booting-thing. Chrome OS and Android's Verified Boot do similar things and have the same expectations about the uid-0/ring-0 separation.) The goal for that bright line on Chrome OS and Android is to stop attack persistence. We want to know that a reboot onto a new kernel and OS image will actually result in getting the desired system state, and that any attack on persistent system data (even for things running with full root privileges) can't result in using kernel interfaces to gain kernel control. This isn't expected to be _perfect_, since nothing is. But it creates a place to work from. The idea that uid-0 is NOT ring-0 is still relatively new, so the existing designs in the kernel aren't well suited to building that distinction. I view this series as a solid first step to getting there, though. -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 18:45 ` Kees Cook @ 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:07 ` Kees Cook 0 siblings, 1 reply; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 19:01 UTC (permalink / raw) To: Kees Cook Cc: Andy Lutomirski, Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, linux-efi On Tue, Apr 3, 2018 at 11:45 AM, Kees Cook <keescook@chromium.org> wrote: > On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski <luto@kernel.org> wrote: >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: >>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: >>>> Can you explain that much more clearly? I'm asking why booting via >>>> UEFI Secure Boot should enable lockdown, and I don't see what this has >>>> to do with kexec. And "someone blacklist[ing] your key in the >>>> bootloader" sounds like a political issue, not a technical issue. >>> >>> A kernel that allows users arbitrary access to ring 0 is just an >>> overfeatured bootloader. Why would you want secure boot in that case? >> >> To get a chain of trust. I can provision a system with some public >> keys, stored in UEFI authenticated variables, such that the system >> will only boot a signed image. That signed image, can, in turn, load >> a signed (or hashed or otherwise verfified) kernel and a verified >> initramfs. The initramfs can run a full system from a verified (using >> dm-verity or similar) filesystem, for example. Now it's very hard to >> persistently attack this system. Chromium OS does something very much >> like this, except that it doesn't use UEFI as far as I know. So does >> iOS, and so do some Android versions. > > Correct, Chrome OS does not use UEFI, and we still want this patch > series, as it plugs all the known "intentional" escalation paths from > uid-0 to ring-0. Happily, that means all the politics around the UEFI > and Secure Boot case can be ignored, because those issues are specific > to Secure Boot, not the lockdown series. (They are _related_, sure, > but lockdown isn't only about Secure Boot -- it's just that SB is one > of the widely deployed implementations of this kind of > trust-chain-booting-thing. Chrome OS and Android's Verified Boot do > similar things and have the same expectations about the uid-0/ring-0 > separation.) > > The goal for that bright line on Chrome OS and Android is to stop > attack persistence. We want to know that a reboot onto a new kernel > and OS image will actually result in getting the desired system state, > and that any attack on persistent system data (even for things running > with full root privileges) can't result in using kernel interfaces to > gain kernel control. This isn't expected to be _perfect_, since > nothing is. But it creates a place to work from. The idea that uid-0 > is NOT ring-0 is still relatively new, so the existing designs in the > kernel aren't well suited to building that distinction. I view this > series as a solid first step to getting there, though. > But wouldn't Chrome OS possibly want to lock down kernel memory write vectors but not read vectors? After all, debugging is useful even on Chrome OS. --Andy ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 19:01 ` Andy Lutomirski @ 2018-04-03 19:07 ` Kees Cook 0 siblings, 0 replies; 116+ messages in thread From: Kees Cook @ 2018-04-03 19:07 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, linux-efi On Tue, Apr 3, 2018 at 12:01 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 3, 2018 at 11:45 AM, Kees Cook <keescook@chromium.org> wrote: >> On Tue, Apr 3, 2018 at 9:45 AM, Andy Lutomirski <luto@kernel.org> wrote: >>> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: >>>> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: >>>>> Can you explain that much more clearly? I'm asking why booting via >>>>> UEFI Secure Boot should enable lockdown, and I don't see what this has >>>>> to do with kexec. And "someone blacklist[ing] your key in the >>>>> bootloader" sounds like a political issue, not a technical issue. >>>> >>>> A kernel that allows users arbitrary access to ring 0 is just an >>>> overfeatured bootloader. Why would you want secure boot in that case? >>> >>> To get a chain of trust. I can provision a system with some public >>> keys, stored in UEFI authenticated variables, such that the system >>> will only boot a signed image. That signed image, can, in turn, load >>> a signed (or hashed or otherwise verfified) kernel and a verified >>> initramfs. The initramfs can run a full system from a verified (using >>> dm-verity or similar) filesystem, for example. Now it's very hard to >>> persistently attack this system. Chromium OS does something very much >>> like this, except that it doesn't use UEFI as far as I know. So does >>> iOS, and so do some Android versions. >> >> Correct, Chrome OS does not use UEFI, and we still want this patch >> series, as it plugs all the known "intentional" escalation paths from >> uid-0 to ring-0. Happily, that means all the politics around the UEFI >> and Secure Boot case can be ignored, because those issues are specific >> to Secure Boot, not the lockdown series. (They are _related_, sure, >> but lockdown isn't only about Secure Boot -- it's just that SB is one >> of the widely deployed implementations of this kind of >> trust-chain-booting-thing. Chrome OS and Android's Verified Boot do >> similar things and have the same expectations about the uid-0/ring-0 >> separation.) >> >> The goal for that bright line on Chrome OS and Android is to stop >> attack persistence. We want to know that a reboot onto a new kernel >> and OS image will actually result in getting the desired system state, >> and that any attack on persistent system data (even for things running >> with full root privileges) can't result in using kernel interfaces to >> gain kernel control. This isn't expected to be _perfect_, since >> nothing is. But it creates a place to work from. The idea that uid-0 >> is NOT ring-0 is still relatively new, so the existing designs in the >> kernel aren't well suited to building that distinction. I view this >> series as a solid first step to getting there, though. > > But wouldn't Chrome OS possibly want to lock down kernel memory write > vectors but not read vectors? After all, debugging is useful even on > Chrome OS. Chrome OS absolutely wants to block writing. We also want to block reading as much as we possibly can, though yes we bump up against debugging in that quest. But those cases are manageable and specific, IMO. -Kees -- Kees Cook Pixel Security ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 16:45 ` Andy Lutomirski 2018-04-03 18:45 ` Kees Cook @ 2018-04-03 19:29 ` Matthew Garrett 2018-04-03 21:51 ` Andy Lutomirski 1 sibling, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 19:29 UTC (permalink / raw) To: luto Cc: David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: > > A kernel that allows users arbitrary access to ring 0 is just an > > overfeatured bootloader. Why would you want secure boot in that case? > To get a chain of trust. I can provision a system with some public > keys, stored in UEFI authenticated variables, such that the system > will only boot a signed image. That signed image, can, in turn, load > a signed (or hashed or otherwise verfified) kernel and a verified > initramfs. The initramfs can run a full system from a verified (using > dm-verity or similar) filesystem, for example. Now it's very hard to > persistently attack this system. Chromium OS does something very much > like this, except that it doesn't use UEFI as far as I know. So does > iOS, and so do some Android versions. None of this requires lockdown, > or even a separation between usermode and kernelmode, to work > correctly. One could even do this on an MMU-less system if one really > cared to. More usefully, someone probably has done this using a > unikernel. That's only viable if you're the only person with the ability to sign stuff for your machine - the moment there are generic distributions that your machine trusts, an attacker can use one as a bootloader to compromise your trust chain. Since most UEFI secure boot systems have to trust generic distributions (if you don't trust the third party signing key then your GPU won't post), the ecosystem depends on it not being possible for people to use generic distributions as bootloaders. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 19:29 ` Matthew Garrett @ 2018-04-03 21:51 ` Andy Lutomirski 2018-04-04 18:42 ` Peter Jones 0 siblings, 1 reply; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 21:51 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski <luto@kernel.org> wrote: >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: >> > A kernel that allows users arbitrary access to ring 0 is just an >> > overfeatured bootloader. Why would you want secure boot in that case? > >> To get a chain of trust. I can provision a system with some public >> keys, stored in UEFI authenticated variables, such that the system >> will only boot a signed image. That signed image, can, in turn, load >> a signed (or hashed or otherwise verfified) kernel and a verified >> initramfs. The initramfs can run a full system from a verified (using >> dm-verity or similar) filesystem, for example. Now it's very hard to >> persistently attack this system. Chromium OS does something very much >> like this, except that it doesn't use UEFI as far as I know. So does >> iOS, and so do some Android versions. None of this requires lockdown, >> or even a separation between usermode and kernelmode, to work >> correctly. One could even do this on an MMU-less system if one really >> cared to. More usefully, someone probably has done this using a >> unikernel. > > That's only viable if you're the only person with the ability to sign stuff > for your machine - the moment there are generic distributions that your > machine trusts, an attacker can use one as a bootloader to compromise your > trust chain. If you removed "as a bootloader", then I agree with that sentence. Can someone please explain why the UEFI crowd cares so much about "as a bootloader"? Once I'm able to install an OS (Linux kernel + bootloader, Windows embedded doodad, OpenBSD, whatever) on your machine, I can use your peripherals, read your data, write your data, see your keystrokes, use your network connection, re-flash your BIOS (at least as well as any OS can), run VMs, and generally own your system. Somehow you all seem fine with all of this, except that the fact that I can chainload something else gives UEFI people the willies. Can someone explain why? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:51 ` Andy Lutomirski @ 2018-04-04 18:42 ` Peter Jones 2018-04-04 20:01 ` Thomas Gleixner ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Peter Jones @ 2018-04-04 18:42 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote: > On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett <mjg59@google.com> wrote: > > On Tue, Apr 3, 2018 at 9:46 AM Andy Lutomirski <luto@kernel.org> wrote: > >> On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: > >> > A kernel that allows users arbitrary access to ring 0 is just an > >> > overfeatured bootloader. Why would you want secure boot in that case? > > > >> To get a chain of trust. I can provision a system with some public > >> keys, stored in UEFI authenticated variables, such that the system > >> will only boot a signed image. That signed image, can, in turn, load > >> a signed (or hashed or otherwise verfified) kernel and a verified > >> initramfs. The initramfs can run a full system from a verified (using > >> dm-verity or similar) filesystem, for example. Now it's very hard to > >> persistently attack this system. Chromium OS does something very much > >> like this, except that it doesn't use UEFI as far as I know. So does > >> iOS, and so do some Android versions. None of this requires lockdown, > >> or even a separation between usermode and kernelmode, to work > >> correctly. One could even do this on an MMU-less system if one really > >> cared to. More usefully, someone probably has done this using a > >> unikernel. > > > > That's only viable if you're the only person with the ability to sign stuff > > for your machine - the moment there are generic distributions that your > > machine trusts, an attacker can use one as a bootloader to compromise your > > trust chain. > > > If you removed "as a bootloader", then I agree with that sentence. > > Can someone please explain why the UEFI crowd cares so much about "as > a bootloader"? Once I'm able to install an OS (Linux kernel + > bootloader, Windows embedded doodad, OpenBSD, whatever) on your > machine, I can use your peripherals, read your data, write your data, > see your keystrokes, use your network connection, re-flash your BIOS > (at least as well as any OS can), run VMs, and generally own your > system. Somehow you all seem fine with all of this, except that the > fact that I can chainload something else gives UEFI people the > willies. > > Can someone explain why? There's no inherent difference, in terms of the trust chain, between compromising it to use the machine as a toaster or to run a botnet - the trust chain is compromised either way. But you're much more likely to notice if your desktop starts producing bread products than if it hides some malware and keeps on booting, and the second one is much more attractive to attackers anyway. The reason we talk about it as a bootloader is because of the model employed by malware. I'm sure you know that one kind of malware that exists in the wild, a so-called "boot kit", operates by modifying a kernel during load (or on disk before loading) so that it has some malicious payload, like exfiltrating user data or allowing a way to install software that the kernel hides or *whatever*, and incorporating some way to achieve relative persistence on the system - for example hiding the real boot settings and loading a kernel with a different than normal initramfs that loads an exploit before continuing with a normal looking boot. As Kees has pointed out, the lockdown portion of this is about separating uid-0 from ring-0. There are a lot of reasons to want to do that, of course. But the reason Secure Boot exists, and ultimately the reason we started trying to do this, is so you can't build the persistence mechanism for a boot kit by using a trusted kernel to springboard into a modified one, even if it's the same kernel just modified before kexec. If you can do that, you can use that to build the persistence mechanism in a boot kit. That is to say, as a result of the way malware has been written, our way of thinking about it is often that it's a way to build a boot loader for a malicious kernel, so that's how we wind up talking about it. Are we concerned with malware stealing your data? Yes, but Secure Boot is only indirectly about that. It's primarily about denying the malware easy mechanisms to build a persistence mechanism. The uid-0 != ring-0 aspect is useful independent of Secure Boot, but Secure Boot without it falls way short of accomplishing its goal. -- Peter ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 18:42 ` Peter Jones @ 2018-04-04 20:01 ` Thomas Gleixner 2018-04-04 20:18 ` Matthew Garrett 2018-04-05 18:47 ` Andy Lutomirski 2018-04-06 4:42 ` Peter Dolding 2 siblings, 1 reply; 116+ messages in thread From: Thomas Gleixner @ 2018-04-04 20:01 UTC (permalink / raw) To: Peter Jones Cc: Andy Lutomirski, Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Wed, 4 Apr 2018, Peter Jones wrote: > That is to say, as a result of the way malware has been written, our way > of thinking about it is often that it's a way to build a boot loader for > a malicious kernel, so that's how we wind up talking about it. Are we > concerned with malware stealing your data? Yes, but Secure Boot is only > indirectly about that. It's primarily about denying the malware easy > mechanisms to build a persistence mechanism. The uid-0 != ring-0 aspect > is useful independent of Secure Boot, but Secure Boot without it falls > way short of accomplishing its goal. I think we can all agree that The uid-0 != ring-0 aspect is useful independent of Secure Boot There is probably resonable consensus about the second part of this sentence as well: but Secure Boot without it falls way short of accomplishing its goal. Now where the disagreement lies is the way how the uid/ring0 aspect is tied to secure boot, which makes it impossible to be useful independent of Secure Boot. So the real question is, how can we make 'lockdown' usable and useful without Secure Boot and at the same time not violate the constraints of the Secure Boot scenario. If we can agree on the above then I hope that we can focus on the technical problems instead of arguing in circles. Thanks, tglx ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 20:01 ` Thomas Gleixner @ 2018-04-04 20:18 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 20:18 UTC (permalink / raw) To: tglx Cc: pjones, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 1:01 PM Thomas Gleixner <tglx@linutronix.de> wrote: > Now where the disagreement lies is the way how the uid/ring0 aspect is tied > to secure boot, which makes it impossible to be useful independent of > Secure Boot. It doesn't - you can pass a command line parameter that enables it, or your bootloader can set the bootparams flag. I don't see a fundamental problem with offering the opportunity to change it at runtime, other than that some stuff that was previously initialised may have to be torn down. The reason for having the UEFI boot stub *optionally* check the secure boot state itself and make a policy decision (rather than having the signed bootloader do so) is because the kernel can be launched directly by the firmware. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 18:42 ` Peter Jones 2018-04-04 20:01 ` Thomas Gleixner @ 2018-04-05 18:47 ` Andy Lutomirski 2018-04-06 4:42 ` Peter Dolding 2 siblings, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-05 18:47 UTC (permalink / raw) To: Peter Jones Cc: Andy Lutomirski, Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 11:42 AM, Peter Jones <pjones@redhat.com> wrote: > On Tue, Apr 03, 2018 at 02:51:23PM -0700, Andy Lutomirski wrote: >> On Tue, Apr 3, 2018 at 12:29 PM, Matthew Garrett <mjg59@google.com> wrote: >> Can someone please explain why the UEFI crowd cares so much about "as >> a bootloader"? Once I'm able to install an OS (Linux kernel + >> bootloader, Windows embedded doodad, OpenBSD, whatever) on your >> machine, I can use your peripherals, read your data, write your data, >> see your keystrokes, use your network connection, re-flash your BIOS >> (at least as well as any OS can), run VMs, and generally own your >> system. Somehow you all seem fine with all of this, except that the >> fact that I can chainload something else gives UEFI people the >> willies. >> >> Can someone explain why? > > There's no inherent difference, in terms of the trust chain, between > compromising it to use the machine as a toaster or to run a botnet - the > trust chain is compromised either way. But you're much more likely to > notice if your desktop starts producing bread products than if it hides > some malware and keeps on booting, and the second one is much more > attractive to attackers anyway. > > The reason we talk about it as a bootloader is because of the model > employed by malware. I'm sure you know that one kind of malware that > exists in the wild, a so-called "boot kit", operates by modifying a > kernel during load (or on disk before loading) so that it has some > malicious payload, like exfiltrating user data or allowing a way to > install software that the kernel hides or *whatever*, and incorporating > some way to achieve relative persistence on the system - for example > hiding the real boot settings and loading a kernel with a different than > normal initramfs that loads an exploit before continuing with a normal > looking boot. This is a fair point, but I wonder how much it matters in practice. If I'm writing a bootkit, I can think of at least four ways to do it. 1. The easy way. Write a malicious bootloader that modifies the kernel image to insert malicious code. Stock secure boot makes this awkward because you need a signed bootloader. It's worth noting that a non-locked-down signed Linux kernel is actually a rather awkward way to do this because it will add several seconds to the boot and may show a splash screen unless you're rather careful. 2. The CPL3 way. Write a malicious initramfs that inserts the malicious code in PID 1 instead. This might be easier to get working across a variety of Linux kernels, but it's more awkward to hide well from userspace. Conventional secure boot (with the stock MS keys) doesn't help at all. 3. The nasty way. Find a known exploitable kernel or bootloader, and use it to do your evil deeds. This is very, very hard to protect against with normal secure boot. 4. The VM-kit way. Use a signed, locked down, perfectly secure kernel and run your pwned system as a VM guest. Secure boot doesn't help one whit. *All* of these variants are avoided by a real, working verified boot approach that chains all the way down to the running system image, and *that* solution doesn't need cpl0 and cpl3 to be separated. So I find myself wondering whether the bootkit argument is actually very compelling. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 18:42 ` Peter Jones 2018-04-04 20:01 ` Thomas Gleixner 2018-04-05 18:47 ` Andy Lutomirski @ 2018-04-06 4:42 ` Peter Dolding 2 siblings, 0 replies; 116+ messages in thread From: Peter Dolding @ 2018-04-06 4:42 UTC (permalink / raw) To: Peter Jones Cc: Andy Lutomirski, Matthew Garrett, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi > > There's no inherent difference, in terms of the trust chain, between > compromising it to use the machine as a toaster or to run a botnet - the > trust chain is compromised either way. But you're much more likely to > notice if your desktop starts producing bread products than if it hides > some malware and keeps on booting, and the second one is much more > That is to say, as a result of the way malware has been written, our way > of thinking about it is often that it's a way to build a boot loader for > a malicious kernel, so that's how we wind up talking about it. Are we > concerned with malware stealing your data? Yes, but Secure Boot is only > indirectly about that. It's primarily about denying the malware easy > mechanisms to build a persistence mechanism. The uid-0 != ring-0 aspect > is useful independent of Secure Boot, but Secure Boot without it falls > way short of accomplishing its goal. > > -- I am sorry the issue here this is really expanding Secure Boot to breaking point. Yes a person wants a secure system having the boot parts verified by some means and using a lockdown is advantage. Problem comes in with the idea that UEFI Secure Boot and lockdown are linked. If I am running windows and linux on the same machine Secure Boot need to be on so windows run happy. Remember its my machine. If I wish to compromise security on my machine because it make sense I should be allowed to, A proper lockdown would prevent you from messing with ACPI tables it a very creative hack have kernel load a DSDT and have it from ring zero turn bits in the kernel off. The reality here is we need to be able to operate without lockdown due to how badly broken some hardware it to configure system. Yes the need to include option to push button to disable secure boot is required due to how badly broken this stuff is. Of course this does not address the issue that if I am working on a system from remote or embedded where I don't have the push button to turn off as a option this is still a problem. Effective lockdown has to protect linux kernel boot parameters, initramfs and other bits from being modified as well. This lead us to problem with the broken hardware in a machine we cannot turn secure boot off we still need to perform all these alterations. We do not live in a world of perfect computer hardware so at this stage proper unattackable secureboot cannot be done. We would be better off putting effort into improve means with UEFI of adding own KEK. This is so that only boot loaders and kernels from the vendors user has approved in fact to work. There could also be a configuration KEK that gets disabled after all the required operating systems are installed. So Microsoft non OS KEK makes sense to be the configuration rule breaking KEK but the current deployments of UEFI don't have a off switch option on it. One KEK for everyone who is not Microsoft to boot with is highly insecure. UEFI secureboot falls way short in the validation department currently because too much is validated under one KEK key. UEFI also fall short due to failing to provide a system to protect boot parameters that can alter OS behaviour and make a secure kernel insecure this include kernels with this lockdown patches, Really you need to compare UEFI secureboot vs boot loader and /boot on a read only media. Every where you can change something in the UEFI secureboot without is being signed that you cannot in the read only media of the boot loader and /boot is a defect in the UEFI secureboot design and implementation. If boot parameters were properly secured there would be no need for lockdown query if UEFI was in secureboot mode or not. Also lockdown being on and kernel and boot loader not running secured still would provide extra item attacker has to get past. So fairly much remove the EFI interrogation patches and work with UEFI to fix it properly. Hacking around these UEFI defects means we will end up being stuck with them and the system still not being properly secured. Peter Dolding ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 16:29 ` Matthew Garrett 2018-04-03 16:45 ` Andy Lutomirski @ 2018-04-03 17:16 ` David Howells 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:49 ` David Howells 2018-04-03 20:53 ` Linus Torvalds 2 siblings, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-03 17:16 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@kernel.org> wrote: > > A kernel that allows users arbitrary access to ring 0 is just an > > overfeatured bootloader. Why would you want secure boot in that case? > > To get a chain of trust. You don't have a chain of trust that you can trust in that case. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 17:16 ` David Howells @ 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:49 ` David Howells 1 sibling, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 19:01 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi > On Apr 3, 2018, at 10:16 AM, David Howells <dhowells@redhat.com> wrote: > > Andy Lutomirski <luto@kernel.org> wrote: > >>> A kernel that allows users arbitrary access to ring 0 is just an >>> overfeatured bootloader. Why would you want secure boot in that case? >> >> To get a chain of trust. > > You don't have a chain of trust that you can trust in that case. > Please elaborate on why I can’t trust it. Please also elaborate on how lockdown helps at all. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 17:16 ` David Howells 2018-04-03 19:01 ` Andy Lutomirski @ 2018-04-03 19:49 ` David Howells 2018-04-03 21:58 ` Andy Lutomirski 2018-04-03 22:32 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-03 19:49 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@kernel.org> wrote: > >>> A kernel that allows users arbitrary access to ring 0 is just an > >>> overfeatured bootloader. Why would you want secure boot in that case? > >> > >> To get a chain of trust. > > > > You don't have a chain of trust that you can trust in that case. > > > Please elaborate on why I can’t trust it. If the user can arbitrarily modify the running kernel image, you cannot trust anything. You cannot determine the trustworthiness of something because your basis for determining that trust can be compromised. > Please also elaborate on how lockdown helps at all. Stopping the kernel from being arbitrarily modified allows you to preserve your trust. Stopping the kernel from being arbitrarily read stops any encryption keys it may be using from being retrieved. And, if you can't guarantee the trustworthiness of your own image, you can't pass the trust onto the next image that you kexec. Now, I can't guarantee that my patches close every hole, they just close all the holes I know about - including some obscure ones like using DMA-capable ISA devices to hack/access the kernel image. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 19:49 ` David Howells @ 2018-04-03 21:58 ` Andy Lutomirski 2018-04-03 22:32 ` David Howells 1 sibling, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 21:58 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 12:49 PM, David Howells <dhowells@redhat.com> wrote: > Andy Lutomirski <luto@kernel.org> wrote: > >> >>> A kernel that allows users arbitrary access to ring 0 is just an >> >>> overfeatured bootloader. Why would you want secure boot in that case? >> >> >> >> To get a chain of trust. >> > >> > You don't have a chain of trust that you can trust in that case. >> > >> Please elaborate on why I can’t trust it. > > If the user can arbitrarily modify the running kernel image, you cannot trust > anything. You cannot determine the trustworthiness of something because your > basis for determining that trust can be compromised. I'm having a very, very hard time coming up with a scenario where I can "trust" something if an attacker can get root but can't modify the running kernel image but I can't "trust" something if the attacker can't. About the only think I can come up with is that root generally has a hard time directly reading kernel keyring data. But if we really think that kernel keyring data is so sacred, let's please solve it properly using SGX or some hypervisor doodad like Microsoft's Credential Guard. Protecting the keyring with lockdown is a whole lot of annoyance without all that much gain. > >> Please also elaborate on how lockdown helps at all. > > Stopping the kernel from being arbitrarily modified allows you to preserve > your trust. If I build a voting machine, an ATM, or a server that runs Panera Bread's website, I can certainly issue a press release that says "hey, the bad guy just downloaded tens of millions of customer records, but they didn't actually get to run CPL0 code, so all is well." </sarcasm> > > Stopping the kernel from being arbitrarily read stops any encryption keys it > may be using from being retrieved. If I build a server that runs Panera Bread 2.0's website, and the attacker exploits my machine to steal tens of millions of customer records by getting the machine to talk to some database server using keys that are securely stored in the kernel keyring, I would feel sooooooo much better knowing that the attacker didn't also manage to extract the key that lets the machine talk to the database server. Never mind that the attacker already stole the entire contents of the database. </sarcasm> ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 19:49 ` David Howells 2018-04-03 21:58 ` Andy Lutomirski @ 2018-04-03 22:32 ` David Howells 2018-04-03 22:39 ` Andy Lutomirski 2018-04-03 23:12 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-03 22:32 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@kernel.org> wrote: > > If the user can arbitrarily modify the running kernel image, you cannot > > trust anything. You cannot determine the trustworthiness of something > > because your basis for determining that trust can be compromised. > > I'm having a very, very hard time coming up with a scenario where I > can "trust" something if an attacker can get root but can't modify the > running kernel image but I can't "trust" something if the attacker > can't. Eh? If the attacker can't what? Did you mean to put "can" at the end of that rather than "can't"? I don't see why the kernel-level trust would be compromised if an attacker can't get root and can't modify the running kernel image. Here's a simple scenario: You boot your machine. You have module verification keys in your kernel. You have /dev/mem available for root to read/write. A program running as root can modify the keys in your kernel or just disable the checking code entirely. It can now insmod any module it likes. You may as well not bother with signed modules. In fact, it can modify the running kernel image in any way it likes, without even having to load modules. There's no point bothering with UID/GID checking either. > > Stopping the kernel from being arbitrarily read stops any encryption keys it > > may be using from being retrieved. > > If I build a server that runs Panera Bread 2.0's website, and the > attacker exploits my machine to steal tens of millions of customer > records by getting the machine to talk to some database server using > keys that are securely stored in the kernel keyring, ... I was thinking more in terms of preventing access to the encrypted data on your own disk. The key for that could be unlocked using a TPM, but the session key then has to be retained in RAM for performance reasons unless you can transfer the session key to, say, your SATA controller without it going through the CPU. However, if /dev/mem can be read, any root process can extract the session key for your disk. But, as you suggest, they could also protect secrets used in communications. However, the communications themselves have to be exposed to userspace for userspace to be able to use them. That is unavoidable. The kernel keyring, for example, tries to restrict who can even see a key, much less use it as much as possible - but ptrace() exists... You are no less vulnerable if the key is held in a userspace process; then the attacker can get the key and the data. If the kernel is locked down, the aim is to try and make sure that keys stashed in the kernel cannot be read, though they have to be able to be used, or there's no point to them. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:32 ` David Howells @ 2018-04-03 22:39 ` Andy Lutomirski 2018-04-03 22:46 ` Linus Torvalds 2018-04-03 23:39 ` David Howells 2018-04-03 23:12 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 22:39 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:32 PM, David Howells <dhowells@redhat.com> wrote: > Andy Lutomirski <luto@kernel.org> wrote: > >> > If the user can arbitrarily modify the running kernel image, you cannot >> > trust anything. You cannot determine the trustworthiness of something >> > because your basis for determining that trust can be compromised. >> >> I'm having a very, very hard time coming up with a scenario where I >> can "trust" something if an attacker can get root but can't modify the >> running kernel image but I can't "trust" something if the attacker >> can't. > > Eh? If the attacker can't what? Did you mean to put "can" at the end of that > rather than "can't"? I don't see why the kernel-level trust would be > compromised if an attacker can't get root and can't modify the running kernel > image. Whoops, yes. > > Here's a simple scenario: You boot your machine. You have module verification > keys in your kernel. You have /dev/mem available for root to read/write. A > program running as root can modify the keys in your kernel or just disable the > checking code entirely. It can now insmod any module it likes. You may as > well not bother with signed modules. In fact, it can modify the running > kernel image in any way it likes, without even having to load modules. I don't particularly disagree with any of this, but you seem to be saying "if you've bought into the party line wrt signed modules, you had better enable lockdown, too". I *don't* buy into the party line about why signed modules should be needed for Secure Boot. > There's no point bothering with UID/GID checking either. Give me a break. There's a *huge* difference between a system where only root can load unsigned modules and a system where anyone can load unsigned modules. > >> > Stopping the kernel from being arbitrarily read stops any encryption keys it >> > may be using from being retrieved. >> >> If I build a server that runs Panera Bread 2.0's website, and the >> attacker exploits my machine to steal tens of millions of customer >> records by getting the machine to talk to some database server using >> keys that are securely stored in the kernel keyring, ... > > I was thinking more in terms of preventing access to the encrypted data on > your own disk. The key for that could be unlocked using a TPM, but the > session key then has to be retained in RAM for performance reasons unless you > can transfer the session key to, say, your SATA controller without it going > through the CPU. > > However, if /dev/mem can be read, any root process can extract the session key > for your disk. Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise. > > But, as you suggest, they could also protect secrets used in communications. > However, the communications themselves have to be exposed to userspace for > userspace to be able to use them. That is unavoidable. The kernel keyring, > for example, tries to restrict who can even see a key, much less use it as > much as possible - but ptrace() exists... You are no less vulnerable if the > key is held in a userspace process; then the attacker can get the key and the > data. > > If the kernel is locked down, the aim is to try and make sure that keys > stashed in the kernel cannot be read, though they have to be able to be used, > or there's no point to them. Sure. I have no problem with having an upstream kernel have a lockdown feature, although I think that feature should distinguish between reads and writes. But I don't think the upstream kernel should apply a patch that ties any of this to Secure Boot without a genuine technical reason why it makes sense. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:39 ` Andy Lutomirski @ 2018-04-03 22:46 ` Linus Torvalds 2018-04-03 22:51 ` Matthew Garrett 2018-04-03 23:39 ` David Howells 1 sibling, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 22:46 UTC (permalink / raw) To: Andy Lutomirski Cc: David Howells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski <luto@kernel.org> wrote: > > Sure. I have no problem with having an upstream kernel have a > lockdown feature, although I think that feature should distinguish > between reads and writes. But I don't think the upstream kernel > should apply a patch that ties any of this to Secure Boot without a > genuine technical reason why it makes sense. So this is where I violently agree with Andy. For example, I love signed kernel modules. The fact that I love them has absolutely zero to do with secure boot, though. There is absolutely no linkage between the two issues: I use (self-)signed kernel modules simply because I think it's a good thing in general. The same thing is true of some lockdown patch. Maybe it's a good thing in general. But whether it's a good thing is _entirely_ independent of any secure boot issue. I can see using secure boot without it, but I can very much also see using lockdown without secure boot. The two things are simply entirely orthogonal. They have _zero_ overlap. I'm not seeing why they'd be linked at all in any way. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:46 ` Linus Torvalds @ 2018-04-03 22:51 ` Matthew Garrett 2018-04-03 22:53 ` Andy Lutomirski 2018-04-03 23:08 ` Linus Torvalds 0 siblings, 2 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 22:51 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > For example, I love signed kernel modules. The fact that I love them > has absolutely zero to do with secure boot, though. There is > absolutely no linkage between the two issues: I use (self-)signed > kernel modules simply because I think it's a good thing in general. > The same thing is true of some lockdown patch. Maybe it's a good thing > in general. But whether it's a good thing is _entirely_ independent of > any secure boot issue. I can see using secure boot without it, but I > can very much also see using lockdown without secure boot. > The two things are simply entirely orthogonal. They have _zero_ > overlap. I'm not seeing why they'd be linked at all in any way. Lockdown is clearly useful without Secure Boot (and I intend to deploy it that way for various things), but I still don't understand why you feel that the common case of booting a kernel from a boot chain that's widely trusted derives no benefit from it being harder to subvert that kernel into subverting that boot chain. For cases where you're self-signing and feel happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and everyone's happy? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:51 ` Matthew Garrett @ 2018-04-03 22:53 ` Andy Lutomirski 2018-04-03 23:08 ` Justin Forbes 2018-04-03 23:09 ` Matthew Garrett 2018-04-03 23:08 ` Linus Torvalds 1 sibling, 2 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 22:53 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > <torvalds@linux-foundation.org> > wrote: > >> For example, I love signed kernel modules. The fact that I love them >> has absolutely zero to do with secure boot, though. There is >> absolutely no linkage between the two issues: I use (self-)signed >> kernel modules simply because I think it's a good thing in general. > >> The same thing is true of some lockdown patch. Maybe it's a good thing >> in general. But whether it's a good thing is _entirely_ independent of >> any secure boot issue. I can see using secure boot without it, but I >> can very much also see using lockdown without secure boot. > >> The two things are simply entirely orthogonal. They have _zero_ >> overlap. I'm not seeing why they'd be linked at all in any way. > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > that way for various things), but I still don't understand why you feel > that the common case of booting a kernel from a boot chain that's widely > trusted derives no benefit from it being harder to subvert that kernel into > subverting that boot chain. For cases where you're self-signing and feel > happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and > everyone's happy? I would like to see distros that want Secure Boot to annoy users by enabling Lockdown be honest about the fact that it's an annoyance and adds very little value by having to carry a patch that was rejected by the upstream kernel. -Andy ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:53 ` Andy Lutomirski @ 2018-04-03 23:08 ` Justin Forbes 2018-04-03 23:09 ` Matthew Garrett 1 sibling, 0 replies; 116+ messages in thread From: Justin Forbes @ 2018-04-03 23:08 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthew Garrett, Linus Torvalds, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi [-- Attachment #1: Type: text/plain, Size: 1849 bytes --] On Tue, Apr 3, 2018 at 5:53 PM, Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote: > > On Tue, Apr 3, 2018 at 3:46 PM Linus Torvalds > > <torvalds@linux-foundation.org> > > wrote: > > > >> For example, I love signed kernel modules. The fact that I love them > >> has absolutely zero to do with secure boot, though. There is > >> absolutely no linkage between the two issues: I use (self-)signed > >> kernel modules simply because I think it's a good thing in general. > > > >> The same thing is true of some lockdown patch. Maybe it's a good thing > >> in general. But whether it's a good thing is _entirely_ independent of > >> any secure boot issue. I can see using secure boot without it, but I > >> can very much also see using lockdown without secure boot. > > > >> The two things are simply entirely orthogonal. They have _zero_ > >> overlap. I'm not seeing why they'd be linked at all in any way. > > > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you feel > > that the common case of booting a kernel from a boot chain that's widely > > trusted derives no benefit from it being harder to subvert that kernel > into > > subverting that boot chain. For cases where you're self-signing and feel > > happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n > and > > everyone's happy? > > I would like to see distros that want Secure Boot to annoy users by > enabling Lockdown be honest about the fact that it's an annoyance and > adds very little value by having to carry a patch that was rejected by > the upstream kernel. > > -Andy > They have been carrying those patches for *years* now. If we didn't think there was value in it, we wouldn't be carrying them. [-- Attachment #2: Type: text/html, Size: 2667 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:53 ` Andy Lutomirski 2018-04-03 23:08 ` Justin Forbes @ 2018-04-03 23:09 ` Matthew Garrett 1 sibling, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 23:09 UTC (permalink / raw) To: luto Cc: Linus Torvalds, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:53 PM Andy Lutomirski <luto@kernel.org> wrote: > On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > > that way for various things), but I still don't understand why you feel > > that the common case of booting a kernel from a boot chain that's widely > > trusted derives no benefit from it being harder to subvert that kernel into > > subverting that boot chain. For cases where you're self-signing and feel > > happy about that, you just set CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to n and > > everyone's happy? > I would like to see distros that want Secure Boot to annoy users by > enabling Lockdown be honest about the fact that it's an annoyance and > adds very little value by having to carry a patch that was rejected by > the upstream kernel. I disagree with the assertion that it adds very little value, but if you want to reject a technically useful patch for political reasons then I'm well beyond the point of caring. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:51 ` Matthew Garrett 2018-04-03 22:53 ` Andy Lutomirski @ 2018-04-03 23:08 ` Linus Torvalds 2018-04-03 23:10 ` Linus Torvalds 2018-04-03 23:17 ` Matthew Garrett 1 sibling, 2 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:08 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 3:51 PM, Matthew Garrett <mjg59@google.com> wrote: > > Lockdown is clearly useful without Secure Boot (and I intend to deploy it > that way for various things), but I still don't understand why you feel > that the common case of booting a kernel from a boot chain that's widely > trusted derives no benefit from it being harder to subvert that kernel into > subverting that boot chain. It has NOTHING TO DO WITH "HARDER TO SUBVERT". THE TWO FEATURES HAVE NOTHING TO DO WITH EACH OTHER WHAT-SO-EVER. I do not want my kernel to act differently depending on some really esoteric detail in how it was booted. That is fundamentally wrong. Is that really so hard to understand? Look at it this way: maybe lockdown breaks some application because that app does something odd. I get a report of that happening, and it so happens that the reporter is running the same distro I am, so I try it with his exact kernel configuration, and it works for me. It is *entirely* non-obvious that the reporter happened to run a distro kernel that had secure boot enabled, and I obviously do not. See what the problem is? Tying these things magically together IS A BAD IDEA. And when people ask you why you did it, YOU HAVE YET TO COME UP WITH A SINGLE ACTUAL RESPONSE. Instead, you just ask people why they care, or tell people to not enable it. Seriously, Matthew, it's WRONG to tie things together in magic ways when they have nothing what-so-ever to do with each other. So no. The answer is simply "don't tie the two things together". And dammit, if you tie them together, you had damn well have a good reason. So far, your reasons have _literally_ been "Why not?" and tried to make the onus be on others to explain to you why not. That's not the right approach to begin with, Matthew. The onus is on *you* to explain why you tied them together, not on others to explain to you - over and over - that they have nothing to do with each other. This discussion is over until you give an actual honest-to-goodness reason for why you tied the two features together. No more "Why not?" crap. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:08 ` Linus Torvalds @ 2018-04-03 23:10 ` Linus Torvalds 2018-04-03 23:17 ` Matthew Garrett 1 sibling, 0 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:10 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:08 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > This discussion is over until you give an actual honest-to-goodness > reason for why you tied the two features together. No more "Why not?" > crap. Side note: I suspect the reason is something along the lines of "there are political reasons". But dammit, if that's the case, those should be documented and explained, not answered with "why not" when people ask why something is the case. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:08 ` Linus Torvalds 2018-04-03 23:10 ` Linus Torvalds @ 2018-04-03 23:17 ` Matthew Garrett 2018-04-03 23:26 ` Linus Torvalds 2018-04-03 23:56 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 23:17 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:08 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > That's not the right approach to begin with, Matthew. The onus is on > *you* to explain why you tied them together, not on others to explain > to you - over and over - that they have nothing to do with each other. 1) Secure Boot is intended to permit the construction of a boot chain that only runs ring 0 code that the user considers trustworthy 2) Allowing arbitrary user code to run in ring 0 without affirmative consent on the part of the user is therefore incompatible with the goals of Secure Boot 3) This patchset provides a mechanism to alter the behaviour of the kernel such that it is significantly more difficult for arbitrary user code to run in ring 0 without affirmative user consent 4) Providing a mechanism for automatically enabling this behaviour when running in a context that is intended to restrict access to ring 0 is a rational thing to do, because otherwise it is difficult to achieve the objective in (1) Alternative approaches to achieve (1) rely on severely constraining userland - ChromeOS, for instance, doesn't impose these restrictions at present but also doesn't allow users to run arbitrary applications (you're stuck inside either the Chrome or Android sandbox). So, if the goal is to achieve (1) when the platform is in this state, what's a more reasonable alternative? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:17 ` Matthew Garrett @ 2018-04-03 23:26 ` Linus Torvalds 2018-04-03 23:39 ` Linus Torvalds 2018-04-03 23:45 ` Matthew Garrett 2018-04-03 23:56 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:26 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@google.com> wrote: > > 1) Secure Boot is intended to permit the construction of a boot chain that > only runs ring 0 code that the user considers trustworthy No. That may be *one* intention, for some people. It's not an a-priori one for the actual user. > 2) Allowing arbitrary user code to run in ring 0 without affirmative > consent on the part of the user is therefore incompatible with the goals of > Secure Boot Again, that has absolutely zero relevance. Those goals are not the *users* goals. Be honest now. It wasn't generally users who clamored for it. If the user actually wanted it, and is asking for it, he can enable it. Independently of secure boot, which the user generally has little control over. > 3) This patchset provides a mechanism to alter the behaviour of the kernel > such that it is significantly more difficult for arbitrary user code to run > in ring 0 without affirmative user consent That difficulty already exists, the new thing isn't somehow related to that at all. Look at our "uyou can only load modules if you're root" rules. Or the "you can only load modules if they are signed". See a pattern there? They don't magically enable themselves (or disable themselves) depending on whether you booted with secure boot or not. Yet they are a HELL OF A LOT MORE IMPORTANT than this new patch series. > 4) Providing a mechanism for automatically enabling this behaviour when > running in a context that is intended to restrict access to ring 0 is a > rational thing to do, because otherwise it is difficult to achieve the > objective in (1) No. See why it's *NOT* rational, as explained already several times. Magically changing kernel behavior depending on some subtle and often unintentional bootup behavior detail is completely idiotic. It would be idiotic if it was that "check kernel module signatures" check. This is no less idiotic. Seriously, listen to your own arguments. If they don't make sense for checking kernel module signatures, why the hell would they make sense for something like lockdown. THE TWO THINGS ARE ENTIRELY INDEPENDENT. I'm done with you. You're not listening, and you're repeating bogus arguments that make no sense. No way in hell will I merge anything like this. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:26 ` Linus Torvalds @ 2018-04-03 23:39 ` Linus Torvalds 2018-04-03 23:47 ` Matthew Garrett 2018-04-03 23:45 ` Matthew Garrett 1 sibling, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:39 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. Another way of looking at this: if lockdown is a good idea to enable when you booted using secure boot, then why isn't it a good idea when you *didn't* boot using secure boot? That's the flip side of this whole argument. People who boot without secure boot may be wanting all the same protections. Maybe you have to disable it when you build your own kernel, for example. Does that suddenly mean that lockdown is now a bad idea? And if it does, explain it. Explain why it's a bad idea to enable without secure boot, but is a good idea to enable *with* secure boot. In other words: explain the tie-in. Because I really don't see it. All I see is illogical blathering that tries to conflate issues that have nothing to do with each other. Please explain to me why a distro or a user would want lockdown to be disabled just because the user didn't use secure boot, but suddenly if it's booted on another machine, it's not just a good idea, but mandatory in your world view? Honestly, if I were a distro maintainer, the *last* thing I'd want is the kernel to act fundamentally differently in some security context depending on some random bootup condition. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:39 ` Linus Torvalds @ 2018-04-03 23:47 ` Matthew Garrett 2018-04-04 0:02 ` Linus Torvalds 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 23:47 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:39 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:26 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Magically changing kernel behavior depending on some subtle and often > > unintentional bootup behavior detail is completely idiotic. > Another way of looking at this: if lockdown is a good idea to enable > when you booted using secure boot, then why isn't it a good idea when > you *didn't* boot using secure boot? Because it's then trivial to circumvent and the restrictions aren't worth the benefit. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:47 ` Matthew Garrett @ 2018-04-04 0:02 ` Linus Torvalds 2018-04-04 0:04 ` Matthew Garrett 0 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:02 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett <mjg59@google.com> wrote: >> Another way of looking at this: if lockdown is a good idea to enable >> when you booted using secure boot, then why isn't it a good idea when >> you *didn't* boot using secure boot? > > Because it's then trivial to circumvent and the restrictions aren't worth > the benefit. Bullshit. If there those restrictions cause problems, they need to be fixed regardless. In fact, from a debuggability standpoint, you want to find the problems early, on those kernel development machines that had secure boot explicitly turned off because it's such a pain. And if they can't be fixed, then the user is going to disable lockdown regardless of how he booted the machine. In no situation is "depending on how you booted" a good choice. Either you can enable it or you can't. If you can, good. And if you can't, it has nothing to do with secure boot. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:02 ` Linus Torvalds @ 2018-04-04 0:04 ` Matthew Garrett 2018-04-04 0:08 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:04 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:02 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:47 PM, Matthew Garrett <mjg59@google.com> wrote: > >> Another way of looking at this: if lockdown is a good idea to enable > >> when you booted using secure boot, then why isn't it a good idea when > >> you *didn't* boot using secure boot? > > > > Because it's then trivial to circumvent and the restrictions aren't worth > > the benefit. > Bullshit. > If there those restrictions cause problems, they need to be fixed regardless. How? When there are random DMA-capable PCI devices that are driven by userland tools that are mmap()ing the BARs out of sysfs, how do we simultaneously avoid breaking those devices while also preventing the majority of users from being vulnerable to an attacker just DMAing over the kernel? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:04 ` Matthew Garrett @ 2018-04-04 0:08 ` Linus Torvalds 2018-04-04 0:12 ` Matthew Garrett 2018-04-04 0:22 ` David Howells 2018-04-05 17:59 ` Alan Cox 2 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:08 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:04 PM, Matthew Garrett <mjg59@google.com> wrote: > > How? When there are random DMA-capable PCI devices that are driven by > userland tools that are mmap()ing the BARs out of sysfs, how do we > simultaneously avoid breaking those devices while also preventing the > majority of users from being vulnerable to an attacker just DMAing over the > kernel? .. if that ends up being a real problem, then you print a warning and tell people to use the kernel command line to disable things. And if it's a big and common problem, then the answer may be that lockdown has to be entirely OFF by default, and you instead just tell people to enable it manually with a kernel command line option. Still better than telling them to disable/enable secure boot, which they may or may not even be able to to. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:08 ` Linus Torvalds @ 2018-04-04 0:12 ` Matthew Garrett 2018-04-05 14:58 ` Alan Cox 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:12 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > Still better than telling them to disable/enable secure boot, which > they may or may not even be able to to. Users who can boot a non-vendor Linux distribution on their platform can disable Secure Boot 100% of the time. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:12 ` Matthew Garrett @ 2018-04-05 14:58 ` Alan Cox 0 siblings, 0 replies; 116+ messages in thread From: Alan Cox @ 2018-04-05 14:58 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, 04 Apr 2018 00:12:04 +0000 Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds > <torvalds@linux-foundation.org> > wrote: > > Still better than telling them to disable/enable secure boot, which > > they may or may not even be able to to. > > Users who can boot a non-vendor Linux distribution on their platform can > disable Secure Boot 100% of the time. So can anyone else, or ignore it. Vendors of all OS's have released enough buggy but signed kernel images over the past years that rummaging around in the archive will find you a wide choice of signed boot images that'll then let you do wtf you like including chaining some other target. It was IMHO broken by design, it's always been broken by design and the horse left the stable several years ago. Key revocation is hard, nobody ever gets it right. Thus "secure" boot is irrelevant to all of this The most useful application of this kind of hardening is against remote attacks. I don't care too much that someone local can attack my machine. They can also steal it, ask me nicely with a baseball bat to remember the password and so on. If my box boots a random unsigned image that has these kinds of hardening enabled then by the time it's on a network it's much much trickier to attack. Yes you might be able to update the boot and reboot - but if I've got that far I can insert an ancient buggy signed kernel image from a vendor and chain through that anyway. Real men boot security sensitive servers off a write protected SD card. If your enterprise vendor doesn't supply a write protect for the boot partition then maybe you should ask them why they don't 8) In some ways the real application for this stuff is embedded. Whatever the boot process most embedded devices benefit from that kind of lock down. Alan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:04 ` Matthew Garrett 2018-04-04 0:08 ` Linus Torvalds @ 2018-04-04 0:22 ` David Howells 2018-04-05 17:59 ` Alan Cox 2 siblings, 0 replies; 116+ messages in thread From: David Howells @ 2018-04-04 0:22 UTC (permalink / raw) To: Linus Torvalds Cc: dhowells, Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Linus Torvalds <torvalds@linux-foundation.org> wrote: > ... use the kernel command line to disable things. An attacker could then modify grub.cfg, say, and cause a reboot (or wait for the next reboot) to disable lockdown:-/ And whilst we could also distribute a non-locked-down variant of the kernel as an alternative, the attacker could install and boot that instead since we can't lock package installation down very easily since it doesn't impinge directly on the running kernel. Unfortunately, it's hard to come up with a disablement mechanism in the kernel that an attacker can't also make use of:-/ David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:04 ` Matthew Garrett 2018-04-04 0:08 ` Linus Torvalds 2018-04-04 0:22 ` David Howells @ 2018-04-05 17:59 ` Alan Cox 2018-04-05 18:03 ` Matthew Garrett 2 siblings, 1 reply; 116+ messages in thread From: Alan Cox @ 2018-04-05 17:59 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi > How? When there are random DMA-capable PCI devices that are driven by > userland tools that are mmap()ing the BARs out of sysfs, how do we > simultaneously avoid breaking those devices while also preventing the > majority of users from being vulnerable to an attacker just DMAing over the > kernel? VT-D ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-05 17:59 ` Alan Cox @ 2018-04-05 18:03 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-05 18:03 UTC (permalink / raw) To: Alan Cox Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Thu, Apr 5, 2018 at 10:59 AM Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote: > VT-D Once Intel provide that on all hardware and actually make it work reliably with their graphics chipsets it's certainly a solution for the PCI DMA problem, but right now it's still effectively undeployable for a lot of real world cases. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:26 ` Linus Torvalds 2018-04-03 23:39 ` Linus Torvalds @ 2018-04-03 23:45 ` Matthew Garrett 2018-04-03 23:55 ` Linus Torvalds 1 sibling, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 23:45 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:26 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:17 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > 1) Secure Boot is intended to permit the construction of a boot chain that > > only runs ring 0 code that the user considers trustworthy > No. > That may be *one* intention, for some people. > It's not an a-priori one for the actual user. Secure Boot is intended to *permit* that. Without Secure Boot you're unable to do that. Some users want that. Some users don't. > > 2) Allowing arbitrary user code to run in ring 0 without affirmative > > consent on the part of the user is therefore incompatible with the goals of > > Secure Boot > Again, that has absolutely zero relevance. > Those goals are not the *users* goals. > Be honest now. It wasn't generally users who clamored for it. If you ask a user whether they want a system that lets an attacker replace their kernel or one that doesn't, what do you think their answer is likely to be? > If the user actually wanted it, and is asking for it, he can enable > it. Independently of secure boot, which the user generally has little > control over. How? If the bootloader will boot kernels that don't impose this restriction then an attacker just replaces whatever's enabling that feature. And, uh, seriously, I've been asking for *years* for someone to point me at a PC on the market that doesn't give the user control over Secure Boot, but Shim was expressly designed to ensure that the user would have the ability to enroll additional trusted keys (or disable signature validation entirely), so which cases are you thinking of where the user doesn't have control? > > 3) This patchset provides a mechanism to alter the behaviour of the kernel > > such that it is significantly more difficult for arbitrary user code to run > > in ring 0 without affirmative user consent > That difficulty already exists, the new thing isn't somehow related to > that at all. > Look at our "uyou can only load modules if you're root" rules. Or the > "you can only load modules if they are signed". > See a pattern there? They don't magically enable themselves (or > disable themselves) depending on whether you booted with secure boot > or not. What's the benefit of "You can only load modules if they are signed" if root is able to just overwrite that policy bit in the kernel? The split between unprivileged users and root is real, but right now module signatures are theater - there's no significant security benefit from them. But the reason to tie this to Secure Boot is that without that an attacker who has root can just replace the kernel on disk (or patch the bootloader to live-patch the kernel on boot, and yes that's an attack we've seen in the real world), so while it's a feature that is arguably beneficial under all circumstances it's a feature that only has significant benefit if you have some way to actually validate what you're booting in the first place. > > 4) Providing a mechanism for automatically enabling this behaviour when > > running in a context that is intended to restrict access to ring 0 is a > > rational thing to do, because otherwise it is difficult to achieve the > > objective in (1) > No. See why it's *NOT* rational, as explained already several times. > Magically changing kernel behavior depending on some subtle and often > unintentional bootup behavior detail is completely idiotic. > It would be idiotic if it was that "check kernel module signatures" > check. This is no less idiotic. > Seriously, listen to your own arguments. If they don't make sense for > checking kernel module signatures, why the hell would they make sense > for something like lockdown. > THE TWO THINGS ARE ENTIRELY INDEPENDENT. Again, what is your proposed mechanism for ensuring that off the shelf systems can be configured in a way that makes this possible? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:45 ` Matthew Garrett @ 2018-04-03 23:55 ` Linus Torvalds 2018-04-03 23:59 ` Matthew Garrett 0 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:55 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett <mjg59@google.com> wrote: >> Be honest now. It wasn't generally users who clamored for it. > > If you ask a user whether they want a system that lets an attacker replace > their kernel or one that doesn't, what do you think their answer is likely > to be? Goddamnit. We both know what the answer will be. And it will have *nothing* to do with secure boot. So *you* be honest now. Because you clearly aren't. Seriously. Go ask that question to a random person: "Do you want a system that lets an attacker replace their kernel or one that doesn't?" and don't ask anything else. Do you really think they'll answer "no, I don't want an attacker to replace my kernel, but only if I booted with secure boot"? Honestly, now. > Again, what is your proposed mechanism for ensuring that off the shelf > systems can be configured in a way that makes this possible? If you think lockdown is a good idea, and you enabled it, then IT IS ENABLED. No idiotic "secure boot or not" garbage. Because secure boot or not isn't *relevant*. Christ, we already have things like - CONFIG_STRICT_KERNEL_RWX - CONFIG_STRICT_DEVMEM - CONFIG_HARDENED_USERCOPY - CONFIG_MODULE_SIG_ALL (and friends) and absolutely *NONE* of them depend on whether the kernel was booted with secure boot or not. And I claim that it would be completely idiotic and broken if they did. And - not entirely unrelated - I claim that it is COMPLETELY IDIOTIC AND BROKEN to make some new "lockdown" option depend on it. Comprende? Really. Your arguments make no sense. They are all fundamentally broken for the simple reason that all your "but secure boot implies XYZ" are pure and utter bullshit, because all your arguments are valid whether secure boot happened or not. See? Secure boot has *NOTHING* do to with anything. It has nothing to do with loading only signed kernel modules. It has nothing to do with your lockdown patches. Either lockdown is good or not. It's that simple. But the goodness has nothing to do with secure boot. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:55 ` Linus Torvalds @ 2018-04-03 23:59 ` Matthew Garrett 2018-04-04 0:06 ` Linus Torvalds 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 23:59 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:55 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:45 PM, Matthew Garrett <mjg59@google.com> wrote: > >> Be honest now. It wasn't generally users who clamored for it. > > > > If you ask a user whether they want a system that lets an attacker replace > > their kernel or one that doesn't, what do you think their answer is likely > > to be? > Goddamnit. > We both know what the answer will be. > And it will have *nothing* to do with secure boot. Right, because they care about outcome rather than mechanism. Secure Boot is the mechanism we have to make that outcome possible. > > Again, what is your proposed mechanism for ensuring that off the shelf > > systems can be configured in a way that makes this possible? > If you think lockdown is a good idea, and you enabled it, then IT IS ENABLED. Ok. So we can build distribution kernels that *always* have this on, and to turn it off you have to disable Secure Boot and install a different kernel. Or we can build distribution kernels that only have this on when you're booting in a context that makes sense, and you can disable it by just disabling Secure Boot (by running mokutil --disable-validation) and not have to install a new kernel. Which outcome do you prefer? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:59 ` Matthew Garrett @ 2018-04-04 0:06 ` Linus Torvalds 2018-04-04 0:10 ` Matthew Garrett 2018-04-04 0:17 ` Jann Horn 0 siblings, 2 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:06 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> wrote: > > Ok. So we can build distribution kernels that *always* have this on, and to > turn it off you have to disable Secure Boot and install a different kernel. Bingo. Exactly like EVERY OTHER KERNEL CONFIG OPTION. Just like all the ones that I've mentioned several times. Or, like a lot of other kernel options, maybe have a way to just disable it on the kernel command line, and let the user know about it. That would still be better than disabling secure boot entirely in your world view, so it's (a) more convenient and (b) better. Again, in no case does it make sense to tie it into "how did we boot". Because that's just inconvenient for everybody. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:06 ` Linus Torvalds @ 2018-04-04 0:10 ` Matthew Garrett 2018-04-04 0:15 ` Linus Torvalds 2018-04-04 0:17 ` Jann Horn 1 sibling, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:10 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:06 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > Ok. So we can build distribution kernels that *always* have this on, and to > > turn it off you have to disable Secure Boot and install a different kernel. > Bingo. > Exactly like EVERY OTHER KERNEL CONFIG OPTION. So your argument is that we should make the user experience worse? Without some sort of verified boot mechanism, lockdown is just security theater. There's no good reason to enable it unless you have some mechanism for verifying that you booted something you trust. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:10 ` Matthew Garrett @ 2018-04-04 0:15 ` Linus Torvalds 2018-04-04 0:16 ` Matthew Garrett 0 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:15 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> wrote: > >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > So your argument is that we should make the user experience worse? Without > some sort of verified boot mechanism, lockdown is just security theater. > There's no good reason to enable it unless you have some mechanism for > verifying that you booted something you trust. Wow. Way to snip the rest of the email where I told you what the solution was. Let me repeat it here, since you so conveniently missed it and deleted it: >> Or, like a lot of other kernel options, maybe have a way to just >> disable it on the kernel command line, and let the user know about it. >> >> That would still be better than disabling secure boot entirely in your >> world view, so it's (a) more convenient and (b) better. Matthew, it's simply not worth continuing talking with you. I'll just not pull this crap, and vendors that you convince to do stupid things have only themselves to blame. You clearly have an agenda, and are not willing to look at arguments against your idiotic choices. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:15 ` Linus Torvalds @ 2018-04-04 0:16 ` Matthew Garrett 2018-04-04 0:18 ` Andy Lutomirski 2018-04-04 0:25 ` Linus Torvalds 0 siblings, 2 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:16 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> wrote: > > > >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > > > So your argument is that we should make the user experience worse? Without > > some sort of verified boot mechanism, lockdown is just security theater. > > There's no good reason to enable it unless you have some mechanism for > > verifying that you booted something you trust. > Wow. Way to snip the rest of the email where I told you what the > solution was. Let me repeat it here, since you so conveniently missed > it and deleted it: I ignored it because it's not a viable option. Part of the patchset disables various kernel command line options. If there's a kernel command line option that disables the patchset then it's pointless. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:16 ` Matthew Garrett @ 2018-04-04 0:18 ` Andy Lutomirski 2018-04-04 0:19 ` Matthew Garrett 2018-04-04 0:25 ` Linus Torvalds 1 sibling, 1 reply; 116+ messages in thread From: Andy Lutomirski @ 2018-04-04 0:18 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 5:15 PM Linus Torvalds > <torvalds@linux-foundation.org> > wrote: >> On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@google.com> wrote: >> > >> >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. >> > >> > So your argument is that we should make the user experience worse? > Without >> > some sort of verified boot mechanism, lockdown is just security theater. >> > There's no good reason to enable it unless you have some mechanism for >> > verifying that you booted something you trust. > >> Wow. Way to snip the rest of the email where I told you what the >> solution was. Let me repeat it here, since you so conveniently missed >> it and deleted it: > > I ignored it because it's not a viable option. Part of the patchset > disables various kernel command line options. If there's a kernel command > line option that disables the patchset then it's pointless. if your secure boot-enabled bootloader can't prevent a bad guy from using malicious kernel command line parameters, then fix it. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:18 ` Andy Lutomirski @ 2018-04-04 0:19 ` Matthew Garrett 2018-04-04 9:04 ` Greg Kroah-Hartman 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:19 UTC (permalink / raw) To: luto Cc: Linus Torvalds, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski <luto@kernel.org> wrote: > if your secure boot-enabled bootloader can't prevent a bad guy from > using malicious kernel command line parameters, then fix it. How is a bootloader supposed to know what the set of malicious kernel command line parameters is? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:19 ` Matthew Garrett @ 2018-04-04 9:04 ` Greg Kroah-Hartman 0 siblings, 0 replies; 116+ messages in thread From: Greg Kroah-Hartman @ 2018-04-04 9:04 UTC (permalink / raw) To: Matthew Garrett Cc: luto, Linus Torvalds, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 12:19:35AM +0000, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 5:18 PM Andy Lutomirski <luto@kernel.org> wrote: > > > if your secure boot-enabled bootloader can't prevent a bad guy from > > using malicious kernel command line parameters, then fix it. > > How is a bootloader supposed to know what the set of malicious kernel > command line parameters is? It wouldn't, it, if it really were "secure", would not allow any command line parameters to be changed. Which is exactly what those bootloaders who "claim" to be secure do. And, just to butt in here, there is no requirement that I have ever heard of from anyone at UEFI or Microsoft that this type of "kernel feature" is a requirement to allow for a bootloader/kernel to be signed with their key. So that should take the "politics" reason off the table here, if people thought that somehow it was even a viable reason... thanks, greg k-h ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:16 ` Matthew Garrett 2018-04-04 0:18 ` Andy Lutomirski @ 2018-04-04 0:25 ` Linus Torvalds 2018-04-04 0:33 ` Linus Torvalds 1 sibling, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:25 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:16 PM, Matthew Garrett <mjg59@google.com> wrote: > > I ignored it because it's not a viable option. Part of the patchset > disables various kernel command line options. If there's a kernel command > line option that disables the patchset then it's pointless. Honestly, I don't think the patchset is viable at all in that case. No way will any sane distribution take it, potentially breaking a lot of machines, and have no way to unbreak them except for "oh, btw, you have to disable secure boot to get things to work again". That would be insane. So you'd better allow some command line options. One reasonable option may be to just disable lockdown by default (to make machines work reliably), and then have a "if you're anal about security, add 'lockdown' to the kernel command line". People who care about this already need to check the secure boot status, so this would be just one more thing they'd check. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:25 ` Linus Torvalds @ 2018-04-04 0:33 ` Linus Torvalds 2018-04-04 0:46 ` Matthew Garrett 0 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:33 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:25 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Honestly, I don't think the patchset is viable at all in that case. .. or rather, it's probably viable only for distributions that already have reasons to only care about controlled hardware environments, ie Chromebooks etc. But a chome OS install wouldn't care about the whole "secure boot or not" issue anyway, because they'd also control that side, an they might as well just enable it unconditionally. In contrast, the generic distros can't enable it anyway if it breaks random hardware. And it wouldn't be about secure boot or not, but about the random hardware choice. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:33 ` Linus Torvalds @ 2018-04-04 0:46 ` Matthew Garrett 2018-04-04 0:56 ` Linus Torvalds 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 0:46 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:33 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > In contrast, the generic distros can't enable it anyway if it breaks > random hardware. And it wouldn't be about secure boot or not, but > about the random hardware choice. The generic distros have been shipping this policy for the past 5 years. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:46 ` Matthew Garrett @ 2018-04-04 0:56 ` Linus Torvalds 2018-04-04 1:13 ` Matthew Garrett ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 0:56 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote: > > The generic distros have been shipping this policy for the past 5 years. .. so apparently it doesn't actually break things? Why not enable it by default then? And if "turn off secure boot" really is the accepted - and actuially used - workaround for the breakage, then WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? Sorry for shouting, but really. We have a thread of just *how* many email messages that asked for the explanation for this? All we got was incomprehensible and illogical crap explanations. If there actually was a good explanation for the tie-in, it should have been front-and-center and explained as such. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:56 ` Linus Torvalds @ 2018-04-04 1:13 ` Matthew Garrett 2018-04-04 1:43 ` Linus Torvalds 2018-04-04 6:56 ` Peter Dolding 2018-04-04 1:30 ` Justin Forbes 2018-04-04 1:36 ` Justin Forbes 2 siblings, 2 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 1:13 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:56 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > The generic distros have been shipping this policy for the past 5 years. > .. so apparently it doesn't actually break things? Why not enable it > by default then? Because it does break things, and the documented fix is "Disable Secure Boot by running mokutil --disable-validation". > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. There are four cases: Verified Boot off, lockdown off: Status quo in distro and mainline kernels Verified Boot off, lockdown on: Perception of security improvement that's trivially circumvented (and so bad) Verified Boot on, lockdown off: Perception of security improvement that's trivially circumvented (and so bad), status quo in mainline kernels Verified Boot on, lockdown on: Security improvement, status quo in distro kernels Of these four options, only two make sense. The most common implementation of Verified Boot on x86 platforms is UEFI Secure Boot, so this patchset includes an option that (if set) results in the kernel doing the right thing without user intervention. This makes it easy for a user to switch between the two states that make sense by running a single command and then following some prompts on the next reboot. The alternative would be to provide a signed kernel that always enabled lockdown and an unsigned kernel that didn't, which would (a) increase load on distributions and (b) force users to both run mokutil --disable-validation and also install a different kernel. I'm sorry if I've appeared tetchy in this discussion - having several of my coworkers shot has not done wonders for my mood. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 1:13 ` Matthew Garrett @ 2018-04-04 1:43 ` Linus Torvalds 2018-04-04 4:30 ` Matthew Garrett 2018-04-04 6:56 ` Peter Dolding 1 sibling, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 1:43 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@google.com> wrote: > > There are four cases: No. Matthew., stop with the agenda already. This shit is what I'm talking about: > Verified Boot off, lockdown on: Perception of security improvement that's > trivially circumvented (and so bad) You're doing some serious value judgement that is simply bogus. If lockdown actually helps avoid CPL0 execution attacks, then it helps even if secure more is off. Sure, you can do things like try to install kernels and reboot, but honestly, that's not "trivially circumvented". It can be quite hard to hide even if you don't have secure boot. Things like disk encryption (common for a lot of people) for example means that you simply won't be booting that machine without the user noticing. Or think of virtual machines - which people often use on purpose for security things. Again, they very much are _not_ going to have secure boot, but it's not necessarily even possible to "replace the kernel and reboot" at all, because the kernel came from outside the virtual machine entirely, and rebooting might just kill the VM rather than restart anything. So I really think you're pushing this whole "not secure boot" means "trivial circumvention" much much too hard. To the point of it being an outright lie. I think the kind of people who run stuff in virtual machines could easily want to also enable lockdown measures, simply to reduce the attack window within that VM. Wouldn't you agree? Those are often security-conscious people. This is what I mean by having an agenda. We all know you are a big proponent of secure boot. But it seems to cloud your arguments, by turning your assumptions and your agenda into an "argument" that is simply not even TRUE. See what I'm unhappy about? > Verified Boot on, lockdown off: Perception of security improvement that's > trivially circumvented (and so bad), status quo in mainline kernels I think this is entirely false too. Again, the "trivial circumvention" shows a bias and agenda that isn't really all that true. > Of these four options, only two make sense. No. You say that, because you have that bias and that agenda. But that simply doesn't make it true. Now, what actually seems to be a real and valid argument is *this* part: > This makes it easy for a user to switch > between the two states that make sense by running a single command and then > following some prompts on the next reboot. The alternative would be to > provide a signed kernel that always enabled lockdown and an unsigned kernel > that didn't, which would (a) increase load on distributions and (b) force > users to both run mokutil --disable-validation and also install a different > kernel. THAT is an actual argument. Admittedly I think it's a horrible hack, but it's a hack that can be explained without outright lying. And it may be a hack that is "the best we can reasonably do" See what I'm saying? One argument is based on your value judgments that not everybody else believes in. The other argument is based purely on cold hard particular facts. Guess which argument is better for people who aren't Matthew Garrett? That said, wouldn't it be equally good to just make the whole thing be a protected EFI variable instead? Once you have physical access to the EFI shell (to turn off secure boot) you have access to that too. Which would allow the "switch off/on" case even if there are other reasons why changing secure boot isn't a great option (possibly because secure boot isn't an option to begin with due to being so invonvenient). Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 1:43 ` Linus Torvalds @ 2018-04-04 4:30 ` Matthew Garrett 2018-04-04 12:57 ` Theodore Y. Ts'o ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 4:30 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 6:43 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 6:13 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > There are four cases: > No. > Matthew., stop with the agenda already. > This shit is what I'm talking about: > > Verified Boot off, lockdown on: Perception of security improvement that's > > trivially circumvented (and so bad) > You're doing some serious value judgement that is simply bogus. > If lockdown actually helps avoid CPL0 execution attacks, then it helps > even if secure more is off. Bear in mind that I'm talking about defaults here - in more constrained configurations the answers may change. But the kernel has no way of knowing whether it's in one of those configurations, and as a result there's an argument for not overpromising on the security that you're providing users. If a user has a configuration where you're able to verify that userspace has some degree of protection (eg, disk encryption keys are in the TPM and won't unseal if someone's switched out the kernel) then it's reasonable for userland (or a kernel command line option) to enable the functionality. What I'm afraid of is this turning into a "security" feature that ends up being circumvented in most scenarios where it's currently deployed - eg, module signatures are mostly worthless in the non-lockdown case because you can just grab the sig_enforce symbol address and then kexec a preamble that flips it back to N regardless of the kernel config. This is the sort of thing that's not obvious to most users, and it potentially causes them to make worse security decisions as a result. The goal for this part of the patchset isn't to cover every single conceivable case, it's to provide reasonable defaults in a way that makes life easier for distributions. > Or think of virtual machines - which people often use on purpose for > security things. Again, they very much are _not_ going to have secure > boot, but it's not necessarily even possible to "replace the kernel > and reboot" at all, because the kernel came from outside the virtual > machine entirely, and rebooting might just kill the VM rather than > restart anything. And where you have a trustworthy external thing providing your kernel, yeah, that's also an argument - and having a kernel command line argument that enables it in this case also seems entirely reasonable. > This is what I mean by having an agenda. We all know you are a big > proponent of secure boot. But it seems to cloud your arguments, by > turning your assumptions and your agenda into an "argument" that is > simply not even TRUE. I'm making this argument from the perspective of "What should the kernel do when it has no additional information". Having the kernel automatically enable lockdown without the user being aware of which guarantees their environment is providing risks giving users the impression of security that they may not have - in that case it makes more sense to have the user make an explicit decision to enable it. > See what I'm unhappy about? > > Verified Boot on, lockdown off: Perception of security improvement that's > > trivially circumvented (and so bad), status quo in mainline kernels > I think this is entirely false too. Again, the "trivial circumvention" > shows a bias and agenda that isn't really all that true. > > Of these four options, only two make sense. > No. > You say that, because you have that bias and that agenda. Ok. Only two make sense *in the absence of additional information about local configuration*. Distributions have to make reasonable choices here, and where a configuration choice decreases functionality and provides what may only be a marginal increase in security it's not a good configuration choice to make by default. > That said, wouldn't it be equally good to just make the whole thing be > a protected EFI variable instead? Once you have physical access to the > EFI shell (to turn off secure boot) you have access to that too. That's pretty much exactly what mokutil does, without you needing to find a copy of the UEFI shell to install first. If you think there's a strong enough need for it, we could definitely add an additional variable that allowed you to disable lockdown without disabling signature validation. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 4:30 ` Matthew Garrett @ 2018-04-04 12:57 ` Theodore Y. Ts'o 2018-04-04 13:02 ` Greg Kroah-Hartman ` (3 more replies) 2018-04-04 13:33 ` David Howells 2018-04-04 16:09 ` Linus Torvalds 2 siblings, 4 replies; 116+ messages in thread From: Theodore Y. Ts'o @ 2018-04-04 12:57 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > What I'm afraid of is this turning into a "security" feature that ends up > being circumvented in most scenarios where it's currently deployed - eg, > module signatures are mostly worthless in the non-lockdown case because you > can just grab the sig_enforce symbol address and then kexec a preamble that > flips it back to N regardless of the kernel config. Whoa. Why doesn't lockdown prevent kexec? Put another away, why isn't this a problem for people who are fearful that Linux could be used as part of a Windows boot virus in a Secure UEFI context? If lockdown simply included a requirement for a signed kernel for kexec --- and if kernel signing aren't available, to simply not alow kexec, wouldn't that take care of this case? This wouldn't even be all that much of a burden for non-distro users with lockdown enabled, since in my experience outside of enterprise and data center use cases, kexec isn't used --- and in fact, very often kexec doesn't even work outside of a very carefully selected and bug-fixed set of device drivers. (It often doesn't work in non-distro kernels because very few upstream developers really care about kexec.) - Ted ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 12:57 ` Theodore Y. Ts'o @ 2018-04-04 13:02 ` Greg Kroah-Hartman 2018-04-04 13:34 ` Theodore Y. Ts'o 2018-04-04 13:29 ` Mike Galbraith ` (2 subsequent siblings) 3 siblings, 1 reply; 116+ messages in thread From: Greg Kroah-Hartman @ 2018-04-04 13:02 UTC (permalink / raw) To: Theodore Y. Ts'o, Matthew Garrett, Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then kexec a preamble that > > flips it back to N regardless of the kernel config. > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? Because no one is afraid of that :) greg k-h ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 13:02 ` Greg Kroah-Hartman @ 2018-04-04 13:34 ` Theodore Y. Ts'o 2018-04-04 13:57 ` Greg Kroah-Hartman 0 siblings, 1 reply; 116+ messages in thread From: Theodore Y. Ts'o @ 2018-04-04 13:34 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: Matthew Garrett, Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > > What I'm afraid of is this turning into a "security" feature that ends up > > > being circumvented in most scenarios where it's currently deployed - eg, > > > module signatures are mostly worthless in the non-lockdown case because you > > > can just grab the sig_enforce symbol address and then kexec a preamble that > > > flips it back to N regardless of the kernel config. > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > isn't this a problem for people who are fearful that Linux could be > > used as part of a Windows boot virus in a Secure UEFI context? > > Because no one is afraid of that :) Well, this is the excuse used by Windows. Some more cynical people believe it's really an anti-competitvie thing, but we should acknowledge this is what is causing the fear that some distros have that their UEFI secure boot certs will be revoked by Microsoft if they don't have this crazy lockdown enforcement for UEFI Secure Boot. So how about this as a compromise. We can have a config option for the behavior that those distros (and Matthew) want, and we can have separate config options that turn things on in what others would say is a more rational way. And I would all be for having the Kconfig description says, "This config option is only needed by distros who are fearful of Microsoft revoking their UEFI secure boot certificate." - Ted ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 13:34 ` Theodore Y. Ts'o @ 2018-04-04 13:57 ` Greg Kroah-Hartman 0 siblings, 0 replies; 116+ messages in thread From: Greg Kroah-Hartman @ 2018-04-04 13:57 UTC (permalink / raw) To: Theodore Y. Ts'o, Matthew Garrett, Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 09:34:11AM -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 03:02:33PM +0200, Greg Kroah-Hartman wrote: > > On Wed, Apr 04, 2018 at 08:57:43AM -0400, Theodore Y. Ts'o wrote: > > > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > > > What I'm afraid of is this turning into a "security" feature that ends up > > > > being circumvented in most scenarios where it's currently deployed - eg, > > > > module signatures are mostly worthless in the non-lockdown case because you > > > > can just grab the sig_enforce symbol address and then kexec a preamble that > > > > flips it back to N regardless of the kernel config. > > > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > > isn't this a problem for people who are fearful that Linux could be > > > used as part of a Windows boot virus in a Secure UEFI context? > > > > Because no one is afraid of that :) > > Well, this is the excuse used by Windows. Really? Every time I have tried to actually follow up on this statement, it turns into an urban myth. If you have proof of this, please let me know, otherwise I am going to keep saying it is false. > Some more cynical people > believe it's really an anti-competitvie thing, but we should > acknowledge this is what is causing the fear that some distros have > that their UEFI secure boot certs will be revoked by Microsoft if they > don't have this crazy lockdown enforcement for UEFI Secure Boot. Unsubstantiated fear of relying on another company's signing key to suddenly stop working is worrying. But it's just that, fear, and not anything that is actually true. We have a working shim binary that is signed, in use by all distros and other operating systems (community and corporate). To revoke that key now would be insane on a variety of levels. So let's stop playing the myth and fear card people, and focus on the actual facts here. > And I would all be for having the Kconfig description says, "This > config option is only needed by distros who are fearful of Microsoft > revoking their UEFI secure boot certificate." Again, no fear please, facts only. thanks, greg k-h ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 12:57 ` Theodore Y. Ts'o 2018-04-04 13:02 ` Greg Kroah-Hartman @ 2018-04-04 13:29 ` Mike Galbraith 2018-04-04 16:20 ` Matthew Garrett 2018-04-08 22:00 ` Pavel Machek 3 siblings, 0 replies; 116+ messages in thread From: Mike Galbraith @ 2018-04-04 13:29 UTC (permalink / raw) To: Theodore Y. Ts'o, Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, 2018-04-04 at 08:57 -0400, Theodore Y. Ts'o wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then kexec a preamble that > > flips it back to N regardless of the kernel config. > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? > > If lockdown simply included a requirement for a signed kernel for > kexec --- and if kernel signing aren't available, to simply not alow > kexec, wouldn't that take care of this case? > > This wouldn't even be all that much of a burden for non-distro users > with lockdown enabled, since in my experience outside of enterprise > and data center use cases, kexec isn't used... Lots of folks use kdump, ergo kexec. -Mike ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 12:57 ` Theodore Y. Ts'o 2018-04-04 13:02 ` Greg Kroah-Hartman 2018-04-04 13:29 ` Mike Galbraith @ 2018-04-04 16:20 ` Matthew Garrett 2018-04-08 22:00 ` Pavel Machek 3 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 16:20 UTC (permalink / raw) To: tytso, Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 5:57 AM Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Wed, Apr 04, 2018 at 04:30:18AM +0000, Matthew Garrett wrote: > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then kexec a preamble that > > flips it back to N regardless of the kernel config. > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? It does - I was talking about the non-lockdown case. In the lockdown case you can only kexec images you trust, so there's no problem. Red Hat have been shipping a signed kdump image for years. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 12:57 ` Theodore Y. Ts'o ` (2 preceding siblings ...) 2018-04-04 16:20 ` Matthew Garrett @ 2018-04-08 22:00 ` Pavel Machek 3 siblings, 0 replies; 116+ messages in thread From: Pavel Machek @ 2018-04-08 22:00 UTC (permalink / raw) To: Theodore Y. Ts'o, Matthew Garrett, Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi [-- Attachment #1: Type: text/plain, Size: 1746 bytes --] Hi! > > What I'm afraid of is this turning into a "security" feature that ends up > > being circumvented in most scenarios where it's currently deployed - eg, > > module signatures are mostly worthless in the non-lockdown case because you > > can just grab the sig_enforce symbol address and then kexec a preamble that > > flips it back to N regardless of the kernel config. > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? > > If lockdown simply included a requirement for a signed kernel for > kexec --- and if kernel signing aren't available, to simply not alow > kexec, wouldn't that take care of this case? > > This wouldn't even be all that much of a burden for non-distro users > with lockdown enabled, since in my experience outside of enterprise > and data center use cases, kexec isn't used --- and in fact, very > often kexec doesn't even work outside of a very carefully selected and > bug-fixed set of device drivers. (It often doesn't work in non-distro > kernels because very few upstream developers really care about kexec.) I do have Motorola Droid 4 here (cellphone). It uses safestrap.. and than it turn kexec's a lot (so that you can select Android vs. Jolla vs. ... during boot). So yes, kexec shows even in unexpected places. And BTW.. the cellphone thingie is a situation where manufacturer works against it users. Motorola does _not_ want me to run my own kernels here. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 4:30 ` Matthew Garrett 2018-04-04 12:57 ` Theodore Y. Ts'o @ 2018-04-04 13:33 ` David Howells 2018-04-04 13:52 ` Theodore Y. Ts'o 2018-04-04 13:57 ` David Howells 2018-04-04 16:09 ` Linus Torvalds 2 siblings, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-04 13:33 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: dhowells, Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi Theodore Y. Ts'o <tytso@mit.edu> wrote: > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > isn't this a problem for people who are fearful that Linux could be > used as part of a Windows boot virus in a Secure UEFI context? Lockdown mode restricts kexec to booting an authorised image (where the authorisation may be by signature or by IMA). David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 13:33 ` David Howells @ 2018-04-04 13:52 ` Theodore Y. Ts'o 2018-04-04 16:22 ` Matthew Garrett 2018-04-04 13:57 ` David Howells 1 sibling, 1 reply; 116+ messages in thread From: Theodore Y. Ts'o @ 2018-04-04 13:52 UTC (permalink / raw) To: David Howells Cc: Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > Theodore Y. Ts'o <tytso@mit.edu> wrote: > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > isn't this a problem for people who are fearful that Linux could be > > used as part of a Windows boot virus in a Secure UEFI context? > > Lockdown mode restricts kexec to booting an authorised image (where the > authorisation may be by signature or by IMA). If that's true, then Matthew's assertion that lockdown w/o secure boot is insecure goes away, no? - Ted ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 13:52 ` Theodore Y. Ts'o @ 2018-04-04 16:22 ` Matthew Garrett 2018-04-04 16:39 ` Andy Lutomirski 2018-04-05 0:05 ` Peter Dolding 0 siblings, 2 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 16:22 UTC (permalink / raw) To: tytso, David Howells, Linus Torvalds, luto, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o <tytso@mit.edu> wrote: > On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: > > Theodore Y. Ts'o <tytso@mit.edu> wrote: > > > > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why > > > isn't this a problem for people who are fearful that Linux could be > > > used as part of a Windows boot virus in a Secure UEFI context? > > > > Lockdown mode restricts kexec to booting an authorised image (where the > > authorisation may be by signature or by IMA). > If that's true, then Matthew's assertion that lockdown w/o secure boot > is insecure goes away, no? If you don't have secure boot then an attacker with root can modify your bootloader or kernel, and on next boot lockdown can be silently disabled. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:22 ` Matthew Garrett @ 2018-04-04 16:39 ` Andy Lutomirski 2018-04-04 16:42 ` Matthew Garrett 2018-04-04 16:46 ` Justin Forbes 2018-04-05 0:05 ` Peter Dolding 1 sibling, 2 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-04 16:39 UTC (permalink / raw) To: Matthew Garrett Cc: Ted Ts'o, David Howells, Linus Torvalds, Andrew Lutomirski, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <mjg59@google.com> wrote: > On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o <tytso@mit.edu> wrote: > >> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >> > Theodore Y. Ts'o <tytso@mit.edu> wrote: >> > >> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why >> > > isn't this a problem for people who are fearful that Linux could be >> > > used as part of a Windows boot virus in a Secure UEFI context? >> > >> > Lockdown mode restricts kexec to booting an authorised image (where the >> > authorisation may be by signature or by IMA). > >> If that's true, then Matthew's assertion that lockdown w/o secure boot >> is insecure goes away, no? > > If you don't have secure boot then an attacker with root can modify your > bootloader or kernel, and on next boot lockdown can be silently disabled. This has been rebutted over and over and over. Secure boot is not the only verified boot mechanism in the world. Other, better, much more auditable, and much simpler mechanisms have been around for a long, long time. >> The fact that this Verified Boot on, lockdown off causes trouble >> points to a clear problem. User owns the hardware they should have >> the right to defeat secureboot if they wish to. > > Which is why Shim allows you to disable validation if you prove physical > user presence. And that's a giant hack. The actual feature should be that a user proves physical presence and thus disables lockdown *without* disabling verification. --Andy ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:39 ` Andy Lutomirski @ 2018-04-04 16:42 ` Matthew Garrett 2018-04-04 16:46 ` Justin Forbes 1 sibling, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 16:42 UTC (permalink / raw) To: luto Cc: tytso, David Howells, Linus Torvalds, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 9:39 AM Andy Lutomirski <luto@kernel.org> wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <mjg59@google.com> wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > This has been rebutted over and over and over. Secure boot is not the > only verified boot mechanism in the world. Other, better, much more > auditable, and much simpler mechanisms have been around for a long, > long time. Right and if you *know* that you're in that situation then you either turn it on in bootparams from the verified bootloader (which we can't do in UEFI because the *firmware* can be the bootloader thanks to the EFI boot stub) or you enable it from userland later (I can't remember if this version of the patchset provides that functionality, but a previous one did). > > Which is why Shim allows you to disable validation if you prove physical > > user presence. > And that's a giant hack. The actual feature should be that a user > proves physical presence and thus disables lockdown *without* > disabling verification. That's a completely reasonable feature request. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:39 ` Andy Lutomirski 2018-04-04 16:42 ` Matthew Garrett @ 2018-04-04 16:46 ` Justin Forbes 1 sibling, 0 replies; 116+ messages in thread From: Justin Forbes @ 2018-04-04 16:46 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthew Garrett, Ted Ts'o, David Howells, Linus Torvalds, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski <luto@kernel.org> wrote: > On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <mjg59@google.com> wrote: >> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o <tytso@mit.edu> wrote: >> >>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote: >>> > Theodore Y. Ts'o <tytso@mit.edu> wrote: >>> > >>> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why >>> > > isn't this a problem for people who are fearful that Linux could be >>> > > used as part of a Windows boot virus in a Secure UEFI context? >>> > >>> > Lockdown mode restricts kexec to booting an authorised image (where the >>> > authorisation may be by signature or by IMA). >> >>> If that's true, then Matthew's assertion that lockdown w/o secure boot >>> is insecure goes away, no? >> >> If you don't have secure boot then an attacker with root can modify your >> bootloader or kernel, and on next boot lockdown can be silently disabled. > > This has been rebutted over and over and over. Secure boot is not the > only verified boot mechanism in the world. Other, better, much more > auditable, and much simpler mechanisms have been around for a long, > long time. > That is certainly the case, and one of the main reasons for the secureboot patchset being split out and lockdown taking a different name. The problem is, right now, secure boot is the only thing using lockdown. I certainly wouldn't go through any effort to tie into it with any other mechanism knowing that this patch set has been delayed upstream for years. I would hope and expect that once lockdown is in mainline, other verified boot mechanisms would leverage it as well. >>> The fact that this Verified Boot on, lockdown off causes trouble >>> points to a clear problem. User owns the hardware they should have >>> the right to defeat secureboot if they wish to. >> >> Which is why Shim allows you to disable validation if you prove physical >> user presence. > > And that's a giant hack. The actual feature should be that a user > proves physical presence and thus disables lockdown *without* > disabling verification. > > --Andy ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:22 ` Matthew Garrett 2018-04-04 16:39 ` Andy Lutomirski @ 2018-04-05 0:05 ` Peter Dolding 2018-04-05 0:20 ` Matthew Garrett 1 sibling, 1 reply; 116+ messages in thread From: Peter Dolding @ 2018-04-05 0:05 UTC (permalink / raw) To: Matthew Garrett Cc: Theodore Tso, David Howells, Linus Torvalds, luto, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi > If you don't have secure boot then an attacker with root can modify your > bootloader or kernel, and on next boot lockdown can be silently disabled. Stop being narrow minded you don't need secure boot to protect bootloader or kernel the classic is only boot from read only media. Another is network boot using https can coreboot firmware. This checks the certificate of the https server against selected CA before downloading anything and as long as the firmware is set read only in hardware the attack has absolutely nothing to work on. In fact the network boot form https server is more secure than UEFI secureboot due to highly limited parties who can alter/provide the approved boot loader/kernel image. Having root user rights does not override physical security. The fact there are other ways of doing bootloader and kernel security other than UEFI secureboot that are in lots of cases more secure than UEFI secureboot due to using more limited keys is the absolute reason why lockdown is required without UEFI secureboot. It would make sense to extend kexec to support UEFI secureboot verification and also kexec to have frameworks to support other security options like https server storage of all kernel images. Please note kexec supporting UEFI secureboot verification should also support booting non UEFI secureboot but verified by some other method and having own PK/KEK set for kexec and this would be when the Linux kernel is placed in firmware and used instead of EFI firmware.. Please note there are many UEFI firmwares that with secureboot off allow setting up secure https bootting where you are not in fact validating the boot loader or kernel but validating the source you get them from. There are three different ways to achieve a protected boot process. 1) validate the boot files.(this is like UEFI secure boot and many other methods) 2) validate source the boot files. Yes this can be apply key check to image if image is not signed don't boot from it and the image contain boot loader and kernel then not bother validating the boot loader and kernel image/parts individually same with https. 3) make boot files read only. All three achieve the same level of security. If you are using any of the three lockdown option may provide some benefit. Yes https network boot effectively does 2 and 3 so making having a very limit threat against the boot process. Remember there is more 1 way to skin a cat just like there is more than 1 way to make a secure system. Currently being too narrow in methods for doing protected booting. Peter Dolding. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-05 0:05 ` Peter Dolding @ 2018-04-05 0:20 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-05 0:20 UTC (permalink / raw) To: Peter Dolding Cc: Theodore Ts'o, David Howells, Linus Torvalds, luto, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 5:05 PM Peter Dolding <oiaohm@gmail.com> wrote: > > If you don't have secure boot then an attacker with root can modify your > > bootloader or kernel, and on next boot lockdown can be silently disabled. > Stop being narrow minded you don't need secure boot to protect > bootloader or kernel the classic is only boot from read only media. And if you use another protected path you can set the appropriate bootparam flag or pass the appropriate kernel command line argument and gain the same functionality. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 13:33 ` David Howells 2018-04-04 13:52 ` Theodore Y. Ts'o @ 2018-04-04 13:57 ` David Howells 1 sibling, 0 replies; 116+ messages in thread From: David Howells @ 2018-04-04 13:57 UTC (permalink / raw) To: Theodore Y. Ts'o Cc: dhowells, Matthew Garrett, Linus Torvalds, luto, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi Theodore Y. Ts'o <tytso@mit.edu> wrote: > > Lockdown mode restricts kexec to booting an authorised image (where the > > authorisation may be by signature or by IMA). > > If that's true, then Matthew's assertion that lockdown w/o secure boot > is insecure goes away, no? No. Lockdown prevents the running kernel from being modified (or, at least, that's the hope). But it doesn't do anything to prevent the kernel being modified before lockdown is engaged. We are trying to use secureboot to protect the system to the point that lockdown can take over. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 4:30 ` Matthew Garrett 2018-04-04 12:57 ` Theodore Y. Ts'o 2018-04-04 13:33 ` David Howells @ 2018-04-04 16:09 ` Linus Torvalds 2018-04-04 16:17 ` Matthew Garrett 2 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 16:09 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett <mjg59@google.com> wrote: > > Bear in mind that I'm talking about defaults here Mattyhew, I really want you to look yourself in the mirror. Those defaults are really horrible defautls for real technical reasons. You asked me why when I questioned this, but then when I replied, you entirely ignored it. So let me repeat: the defaults are *horrible*. They are horrible for a very simple reason: kernel behavior changes that depend on some subtle boot difference are truly nasty to debug, and nasty to get coverage for. And this "subtle boot difference" is really bad because it's a difference that has a particularly bad pattern: pretty much not a single mainline kernel developer will have secure boot enabled, exactly because it's so inconvenient for testing. So what does that mean? It means that the default is *actively* bad for kernel development. It means that the people who do kernel development will not be testing the behavior that "normal" users will actually see. If you do not see why that is a HORRIBLY BAD THING, I don't know what to say. Seriously. It's a nasty nasty default behavior. It's absolutely disastrously wrong. And then when people call you out on this bad linkage of this feature with secure boot, you spent a *LOT* of time being dishonest about it. Instead of answeing a simple technical question, you did just about everything you could to avoid answering it. You initially turned the question back into a "Why would you want to?" rather than just answering. Then you spent a whole lot of time coming up with completely wrong excuses that had no actual technical reason for them. And even now, you're trying to ignore the question, and the REASON for the question. See above: the default is really horrendously bad, and is just about the *worst* default you could ever pick from a kernel development angle. So when a kernel developer - both me and Andy - ask you about the reason for that HORRIBLY BAD default, then you had better stop dancing around the issue, and be honesy. Instead, you bring up complete red herrings: > If a user has a configuration where you're able to verify that userspace > has some degree of protection (eg, disk encryption keys are in the TPM and > won't unseal if someone's switched out the kernel) then it's reasonable for > userland (or a kernel command line option) to enable the functionality. This line of arguyment of yours ends up STILL being complete and utter garbage. There is not a single shred of evidence that there is some kind of "reasonable to enable the functionality" based on completely unrelated matters. See above on why such stupid linkages are a bad bad idea. Absolutely *ANY* time you make that decision silently for a user, you will just be doing the wrong thing. You will do the wrong thing for security, but equally importantly, you will be doing the wrong thing just for *development* and *test coverage*. > What I'm afraid of is this turning into a "security" feature that ends up > being circumvented in most scenarios where it's currently deployed - eg, > module signatures are mostly worthless in the non-lockdown case because you > can just grab the sig_enforce symbol address and then kexec a preamble that > flips it back to N regardless of the kernel config. Honestyly, all of your arguments are made up shit. This argument, for example, is just a complete red herring. Do you want to protect against somebody flipping "sig_enforce"? Makes perfect sense to me. Then WHY is that not just a config option for extra hardening? Seriously. I'd use it. I have never *ever* felt the need to switch "sig_enforce" off, and I always build with MODULE_SIG_FORCE and MODULE_SIG_ALL. Getting rid of that switch entirely for security reasons sounds just _fine_ to me. So you use these *stupid* things as "arguments" for why you think you want to do something. But you're putting the cart before the horse: you have a particular end result you want to get to, and then you make up arguments for why you want to get there. Seriously, go back to that coverage and testing issue. Go back to the *fundamental* technical issue that we want kernel developers to actually *test* the code that users are running. *Gasp*. Yeah, I know, it's a completely radical idea, but it's true. Having developers test and run the code actual real humans are using is a truly revolutionary concept in security too. > I'm making this argument from the perspective of "What should the kernel do > when it has no additional information". And I'm telling you that you're ignoring the fact that you picked a truly horrendously shitty default. And then you spent a *lot* of time giving misleading and bad information about why you picked that shitty default, and instead just questioning the people who asked you an actual and really simply technical question. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:09 ` Linus Torvalds @ 2018-04-04 16:17 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 16:17 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 9:09 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 9:30 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > Bear in mind that I'm talking about defaults here > Mattyhew, I really want you to look yourself in the mirror. > Those defaults are really horrible defautls for real technical reasons. > You asked me why when I questioned this, but then when I replied, you > entirely ignored it. > So let me repeat: the defaults are *horrible*. They are horrible for a > very simple reason: kernel behavior changes that depend on some subtle > boot difference are truly nasty to debug, and nasty to get coverage > for. They're the defaults that the mainline distros have been shipping for years. So what are you actually asking for here? If you're saying that it should be possible to enable the lockdown functionality even in the absence of any kind of verified boot, then yes, I agree - I just think it makes a poor distro default to have that be the case out of the box. If you're saying that it should be possible to disable the lockdown functionality even in the presence of any kind of verified boot, then yes, I agree - I just think it makes a poor distro default to have that be the case out of the box. You're arguing against a patch that provides the default policy that distros want to ship. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 1:13 ` Matthew Garrett 2018-04-04 1:43 ` Linus Torvalds @ 2018-04-04 6:56 ` Peter Dolding 2018-04-04 16:26 ` Matthew Garrett 1 sibling, 1 reply; 116+ messages in thread From: Peter Dolding @ 2018-04-04 6:56 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi . On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@google.com> wrote: > There are four cases: > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > Verified Boot off, lockdown on: Perception of security improvement that's > trivially circumvented (and so bad) > Verified Boot on, lockdown off: Perception of security improvement that's > trivially circumvented (and so bad), status quo in mainline kernels > Verified Boot on, lockdown on: Security improvement, status quo in distro > kernels > > Of these four options, only two make sense. The most common implementation > of Verified Boot on x86 platforms is UEFI Secure Boot, Stop right there. Verified boot does not have to be UEFI secureboot. You could be using a uboot verified boot or https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. Neither of these provide flags to kernel to say they have been performed. So Verified boot looking off to kernel yet lockdown needing to be on is one very valid combination and must be supported because the Linux kernel does not always know when it verified boot environment. When the Linux kernel thinks verified boot is off it may not be trivial to circumvent. Now Verified Boot on, lockdown off. Insanely this can be required in diagnostic on some embedded platform because EFI secureboot does not have a off switch. These are platforms where they don't boot if they don't have a PK and KEK set installed. Yes some of these is jtag the PK and KEK set in. The fact that this Verified Boot on, lockdown off causes trouble points to a clear problem. User owns the hardware they should have the right to defeat secureboot if they wish to. In fact the issue that you can not install a KEK per operating system installed shows a problem as well. So all OS use the same KEK for their installers and then you have all non Microsoft in a lot of cases the same KEK for booting OS. Any of these bootloaders/kernels with defect will end up with the security being exactly like Verified Boot on, lockdown off. Remember attackers will send around copies of what ever they need to so they can breach a system so they find a defective solution some where they will ship it everywhere. Attackers that secureboot is attempted to prevent are criminal anyhow what is a little bit of copyright violation to them.. So when the current UEFI design is security theatre there should not be any special effort to support it. If UEFI was not security theatre there would be a clean way for people install and setup up their systems to list what operating system KEK should be accepted so allowing attack surface area to be minimised and the damaged form any flawed implementation to also be limited. This way end users could opt in or out of operating systems based on security. If user has opted out of all operating systems doing Verified Boot on, lockdown off: those are not a threat. Also any OS with defective kernel or bootloader that the system has not allowed the KEK of would also not be a threat. Really I see no reason to be bending over in the Linux kernel for UEFI secureboot. You list all 4 types need to exist for different usage case of the Linux kernel. The fact UEFI secureboot currently is implemented on x86 does not handle the fact all 4 use cases need to exist is really a issue with UEFI Secureboot that needs to be fixed by those designing UEFI for the future. Allowing the kernel to be configured the 4 different ways does not mean a party like Microsoft has to sign off on everything the Linux kernel can do. Its not like android/IOT vendors have to bow to Microsoft. The Linux kernel should not show favouritism. This does mean that all 4 modes should be in the kernel configuration options. Matthew Garrett your mistake is that only 2 are valid when all 4 are valid in different usage cases. Circumventing security is sometimes required accepting that case is hard for some people. Of course when a party need perform circumventing security the fact that it currently gives out the keys to world of UEFI systems is a very big security design flaw in UEFI. Why should the Linux kernel contain code to work around defective design of UEFI and limit what users not using UEFI and using UEFI can do? Peter Dolding ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 6:56 ` Peter Dolding @ 2018-04-04 16:26 ` Matthew Garrett 2018-04-05 1:28 ` Peter Dolding 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-04 16:26 UTC (permalink / raw) To: oiaohm Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oiaohm@gmail.com> wrote: > On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@google.com> wrote: > > There are four cases: > > > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > > Verified Boot off, lockdown on: Perception of security improvement that's > > trivially circumvented (and so bad) > > Verified Boot on, lockdown off: Perception of security improvement that's > > trivially circumvented (and so bad), status quo in mainline kernels > > Verified Boot on, lockdown on: Security improvement, status quo in distro > > kernels > > > > Of these four options, only two make sense. The most common implementation > > of Verified Boot on x86 platforms is UEFI Secure Boot, > Stop right there. Verified boot does not have to be UEFI secureboot. > You could be using a uboot verified boot or > https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. > Neither of these provide flags to kernel to say they have been > performed. They can be modified to set the appropriate bit in the bootparams - the reason we can't do that in the UEFI case is that Linux can be built as a UEFI binary that the firmware execute directly, and so the firmware has no way to set that flag. > Now Verified Boot on, lockdown off. Insanely this can be required in > diagnostic on some embedded platform because EFI secureboot does not > have a off switch. These are platforms where they don't boot if > they don't have a PK and KEK set installed. Yes some of these is jtag > the PK and KEK set in. > The fact that this Verified Boot on, lockdown off causes trouble > points to a clear problem. User owns the hardware they should have > the right to defeat secureboot if they wish to. Which is why Shim allows you to disable validation if you prove physical user presence. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 16:26 ` Matthew Garrett @ 2018-04-05 1:28 ` Peter Dolding 0 siblings, 0 replies; 116+ messages in thread From: Peter Dolding @ 2018-04-05 1:28 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oiaohm@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@google.com> wrote: > >> > There are four cases: >> > >> > Verified Boot off, lockdown off: Status quo in distro and mainline > kernels >> > Verified Boot off, lockdown on: Perception of security improvement > that's >> > trivially circumvented (and so bad) >> > Verified Boot on, lockdown off: Perception of security improvement > that's >> > trivially circumvented (and so bad), status quo in mainline kernels >> > Verified Boot on, lockdown on: Security improvement, status quo in > distro >> > kernels >> > >> > Of these four options, only two make sense. The most common > implementation >> > of Verified Boot on x86 platforms is UEFI Secure Boot, > >> Stop right there. Verified boot does not have to be UEFI secureboot. >> You could be using a uboot verified boot or >> https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. >> Neither of these provide flags to kernel to say they have been >> performed. > > They can be modified to set the appropriate bit in the bootparams - the > reason we can't do that in the UEFI case is that Linux can be built as a > UEFI binary that the firmware execute directly, and so the firmware has no > way to set that flag. > With some of your embedded hardware boot loaders you have exactly the same problem. Where you cannot set bootparams instead have to hard set everything in the kernel image. This is why there is a option to embedded initramfs image inside kernel image because some of them will only load 1 file. So not using UEFI you run into the exact same problem. So lockdown on or off need to be a kernel build option setting default. This could be 3 options Always on, Always off and "Automatic based on boot verification system status". https://linux.die.net/man/8/efibootmgr Also I have a problem here in non broken UEFI implementations -@ | --append-binary-args that is very simple set the command line passed into UEFI binary loaded by the firmware with the Linux kernel this comes bootparams. Yes using --append-binary-args can be a pain it is used to tell the Linux kernel where to find the / drive. So turning lockdown off by bootparams is down right possible with working UEFI. There is a lot of EFI out there that does not work properly. >> Now Verified Boot on, lockdown off. Insanely this can be required in >> diagnostic on some embedded platform because EFI secureboot does not >> have a off switch. These are platforms where they don't boot if >> they don't have a PK and KEK set installed. Yes some of these is jtag >> the PK and KEK set in. > >> The fact that this Verified Boot on, lockdown off causes trouble >> points to a clear problem. User owns the hardware they should have >> the right to defeat secureboot if they wish to. > > Which is why Shim allows you to disable validation if you prove physical > user presence. Good idea until you have a motherboard where the PS2 ports have failed and does not support usb keyboard so you have no keyboard until after the kernel has booted so no way to prove physical presence. Or are working on something embedded that has no physical user presence interface in the boot stages these embedded devices can also be UEFI with secureboot. Not everything running UEFI has keyboard, screen....anything that you can prove physical user presence with sometimes you have to pure depend on the signing key. If I am a person who has made my own PK and has my own KEK in UEFI system I should have the right to sign kernel with lockdown off by default. I may need this for diagnostics on hardware without user interface and I may need this because the hardware is broken and I have set PK and KEK set by direct firmware flash access possibly by jtag or possibly before critical port on motherboard died. Of course I am not saying that Microsoft and others cannot have rules that say if using their KEK that you cannot do this. But if the machine is my hardware and I have set my own PK and KEK set I do know what I am doing and I should be allowed to compromise security if I wish its my hardware. I should not have to custom hack to do it. Of course I am not saying that the setting in Linux kernel configuration system cannot have a big warning that you should not do this unless you have no other valid option and I am not saying that the kernel should not log/report if it see what appears to be a questionable configuration like dmesg "SECURITY ISSUE: UEFI secureboot detected enabled kernel built with lockdown disabled system at risk of comprise". Something audit tools could check logs for. . So a kernel booting secureboot with lockdown disabled in kernel configuration is perfectly fine to log a message that this is the case. Always forcing lockdown on because you see UEFI secureboot will cause issues. Broken hardware to get around a failed motherboard with UEFI secureboot locked on you may wish to chain load though a kernel that you have the means to sign to boot a different OS that is going to be complex for you to sign due to on going updates. In my eyes lockdown have a kernel configuration option with 5 options setting the mode. 1) Automatic: On if a verified boot system is known to the kernel this may be UEFI secure boot this could be other systems the Linux kernel can detect in future and off if verified boot is not detected/disabled or if user approves turning it off by user presence test., 2) Always on: That no matter what the Linux kernel turns lockdown on. No user action or shim action is going to turn it off. 3) On but user/boot bootparams controllable. So user can give command line to EFI or other boot-loader to turn it off so no user presence test and this is need in some cases.. 4) Always off: that is always off no matter what and put error in dmesg if the Automatic on condition is found. 5) Completely build linux kernel without lockdown code bar with a single dmesg reporting this. 3-5 all provide security risks all have valid usage reasons. 3 you may want command line controllable you are developing on a system with user presence cannot be confirmed and you need to be able to switch between lockdown on and off and you only want to send 1 kernel cross to device in development stages. 4 is simple you have a case where you need lockdown always off line chain loading on a system where things have gone wrong. 5 can quite simply be diagnostics we have a issue we want to absolutely confirm that the lockdown code is not the cause. I can understand if 3-5 are forbin when using Microsoft KEK or other parties KEKs but those building their own kernels using their own keys should not have those restrictions it their hardware it thier configuration if they decide to make it insecure it their choice.. Peter Dolding ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:56 ` Linus Torvalds 2018-04-04 1:13 ` Matthew Garrett @ 2018-04-04 1:30 ` Justin Forbes 2018-04-04 1:58 ` Linus Torvalds 2018-04-04 1:36 ` Justin Forbes 2 siblings, 1 reply; 116+ messages in thread From: Justin Forbes @ 2018-04-04 1:30 UTC (permalink / raw) To: Linus Torvalds Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi [-- Attachment #1: Type: text/plain, Size: 2590 bytes --] On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds < torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things? Why not enable it > by default then? > > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > > While there is very little breakage in the *years* we have been shipping this in distro kernels, the accepted and used workaround has always been "turn off secure boot" or sign/import your own keys, depending on the problems encountered. > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. If there actually was a good explanation for the tie-in, it should > have been front-and-center and explained as such. > > Honestly, yes, the major distros have been shipping this patch set for years now, and every time it comes to upstream, the same damn arguments emerge. I do not disagree that there are uses for lockdown outside of secure boot, provided you have some other mechanism to verify your chain, I believe chrome OS does. But the tie to secure boot is because that is the use case that users have been using for years, it was discussed at kernel summit quite a while ago, plans went forward there seemed to be agreement, and when it comes time for a pull request, people come out of the woodwork with an expectation that it solves every problem or it doesn't need to exist. What is here is a good starting point. I would expect that if it were merged, others would build upon that and use much of the code already in place to extend it. It is tied to secure boot because that is what has been using this for years as it never seems to get upstream. I am sure that once it does finally land, it can and will be extended to other things, but I don't think I would want to spend a lot of time trying to leverage another external patch set that has been delayed upstream so many times until it actually did land. As for the ties to MS that come up every time, and have here as well, there is no requirement on the MS signature. You can import your own keys if you don't want them involved, I keep a "test key" imported for actually running what I build locally. [-- Attachment #2: Type: text/html, Size: 3415 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 1:30 ` Justin Forbes @ 2018-04-04 1:58 ` Linus Torvalds 0 siblings, 0 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-04 1:58 UTC (permalink / raw) To: Justin Forbes Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 6:30 PM, Justin Forbes <jforbes@redhat.com> wrote: >> >> If there actually was a good explanation for the tie-in, it should >> have been front-and-center and explained as such. >> > Honestly, yes, the major distros have been shipping this patch set for years > now, and every time it comes to upstream, the same damn arguments emerge. Well, I think it's because the explanations have been bogus. Just look at this thread. It took closer to a hundred emails (ok, so I'm exaggerating, but not _that_ much) until the *real* reason for the tie-in was actually exposed. For the first 50+ emails, the explanation was "oh, only if you do secure boot does this make sense". Which is still pure BULLSHIT. Of _course_ that kind of stuff raises peoples hackles and makes people not trust the messenger - he's clearly being evasive and there must be something else going on. So instead of the bullshit explanations, just explain the purely _practical_ side. 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". See? No bullshit. Just straight talk about the *actual* reason why people decided on this particular tie-in, and admitting that it's a hack, but also clearly stating the reason for the hack. Now, I still don't necessarily agree that it's the best possible option, but when stated in those terms I at least understand why that option was picked as a reasonable one, and it changes the discussion a lot, and (at least for me) makes it much more palatable. Because as long as the explanation is just some "you must use secure boot or you've already lost and further security is pointless" hocus-pocus magical thinking, I immediately go "no, that sounds completely bogus, and it makes testing and coverage much worse, we've done other things quite like that without this secure boot tie-in". Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:56 ` Linus Torvalds 2018-04-04 1:13 ` Matthew Garrett 2018-04-04 1:30 ` Justin Forbes @ 2018-04-04 1:36 ` Justin Forbes 2 siblings, 0 replies; 116+ messages in thread From: Justin Forbes @ 2018-04-04 1:36 UTC (permalink / raw) To: Linus Torvalds Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 7:56 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 5:46 PM, Matthew Garrett <mjg59@google.com> wrote: >> >> The generic distros have been shipping this policy for the past 5 years. > > .. so apparently it doesn't actually break things? Why not enable it > by default then? > > And if "turn off secure boot" really is the accepted - and actuially > used - workaround for the breakage, then > While there is very little breakage in the *years* we have been shipping this in distro kernels, the accepted and used workaround has always been "turn off secure boot" or sign/import your own keys, depending on the problems encountered. > WHY THE HELL DIDN'T YOU START OFF BY EXPLAINING THAT IN THE FIRST > PLACE WHEN PEOPLE ASKED WHY THE TIE-IN EXISTED? > > Sorry for shouting, but really. We have a thread of just *how* many > email messages that asked for the explanation for this? All we got was > incomprehensible and illogical crap explanations. > > If there actually was a good explanation for the tie-in, it should > have been front-and-center and explained as such. > Honestly, yes, the major distros have been shipping this patch set for years now, and every time it comes to upstream, the same damn arguments emerge. I do not disagree that there are uses for lockdown outside of secure boot, provided you have some other mechanism to verify your chain, I believe chrome OS does. But the tie to secure boot is because that is the use case that users have been using for years, it was discussed at kernel summit quite a while ago, plans went forward there seemed to be agreement, and when it comes time for a pull request, people come out of the woodwork with an expectation that it solves every problem or it doesn't need to exist. What is here is a good starting point. I would expect that if it were merged, others would build upon that and use much of the code already in place to extend it. It is tied to secure boot because that is what has been using this for years as it never seems to get upstream. I am sure that once it does finally land, it can and will be extended to other things, but I don't think I would want to spend a lot of time trying to leverage another external patch set that has been delayed upstream so many times until it actually did land. As for the ties to MS that come up every time, and have here as well, there is no requirement on the MS signature. You can import your own keys if you don't want them involved, I keep a "test key" imported for actually running what I build locally. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:06 ` Linus Torvalds 2018-04-04 0:10 ` Matthew Garrett @ 2018-04-04 0:17 ` Jann Horn 2018-04-04 0:23 ` Andy Lutomirski 2018-04-04 8:05 ` David Howells 1 sibling, 2 replies; 116+ messages in thread From: Jann Horn @ 2018-04-04 0:17 UTC (permalink / raw) To: Linus Torvalds Cc: Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> wrote: >> >> Ok. So we can build distribution kernels that *always* have this on, and to >> turn it off you have to disable Secure Boot and install a different kernel. > > Bingo. > > Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > Just like all the ones that I've mentioned several times. > > Or, like a lot of other kernel options, maybe have a way to just > disable it on the kernel command line, and let the user know about it. > > That would still be better than disabling secure boot entirely in your > world view, so it's (a) more convenient and (b) better. > > Again, in no case does it make sense to tie it into "how did we boot". > Because that's just inconvenient for everybody. Without taking a stance regarding whether I think that kernel lockdown makes sense, I think Matthew's point is this: If you don't have lockdown, secure boot doesn't provide a benefit, since an attacker could just modify the init binary instead of messing with your kernel. If you have secure boot, you want lockdown to prevent chainloading into a backdoored version of the real OS. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:17 ` Jann Horn @ 2018-04-04 0:23 ` Andy Lutomirski 2018-04-04 8:05 ` David Howells 1 sibling, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-04 0:23 UTC (permalink / raw) To: Jann Horn Cc: Linus Torvalds, Matthew Garrett, Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 5:17 PM, Jann Horn <jannh@google.com> wrote: > On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> wrote: >>> >>> Ok. So we can build distribution kernels that *always* have this on, and to >>> turn it off you have to disable Secure Boot and install a different kernel. >> >> Bingo. >> >> Exactly like EVERY OTHER KERNEL CONFIG OPTION. >> >> Just like all the ones that I've mentioned several times. >> >> Or, like a lot of other kernel options, maybe have a way to just >> disable it on the kernel command line, and let the user know about it. >> >> That would still be better than disabling secure boot entirely in your >> world view, so it's (a) more convenient and (b) better. >> >> Again, in no case does it make sense to tie it into "how did we boot". >> Because that's just inconvenient for everybody. > > Without taking a stance regarding whether I think that kernel lockdown > makes sense, I think Matthew's point is this: > If you don't have lockdown, secure boot doesn't provide a benefit, > since an attacker could just modify the init binary instead of messing > with your kernel. > If you have secure boot, you want lockdown to prevent chainloading > into a backdoored version of the real OS. I don't think that's the argument here. Secure boot can be used to protect initramfs, since initramfs comes from the secure boot-verified bootloader. That verified initramfs can protect the init binary. As far as I can tell, what's really going on here is that there's a significant contingent here that wants to prevent Linux from chainloading something that isn't Linux. (There doesn't seem to be a real benefit to preventing Linux from chainloading Linux, since the chainloaded Linux is unlikely to let the attacker do much that the original rooted Linux kernel wouldn't have allowed.) In particular, Microsoft, which de facto controls most of the secure boot key ecosystem, doesn't want Windows to be chainloaded without having its signature verified. I admit I'm not quite sure why Microsoft considers this important. They already require a TPM for all new systems, and any important secrets can be sealed by the TPM such that a maliciously chainloaded Windows kernel couldn't access those secrets. But secure boot predates the WHQL TPM requirement if I remember correctly, and I suspect that we're seeing leftover requirements from secure-boot-but-no-TPM era. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 0:17 ` Jann Horn 2018-04-04 0:23 ` Andy Lutomirski @ 2018-04-04 8:05 ` David Howells 2018-04-04 14:35 ` Andy Lutomirski ` (2 more replies) 1 sibling, 3 replies; 116+ messages in thread From: David Howells @ 2018-04-04 8:05 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Jann Horn, Linus Torvalds, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@kernel.org> wrote: > As far as I can tell, what's really going on here is that there's a > significant contingent here that wants to prevent Linux from > chainloading something that isn't Linux. You have completely the wrong end of the stick. No one has said that or even implied that. You are alleging dishonesty on our part. What we *have* said is that *if* we want to pass the secure boot state across kexec, then we have to make sure that: (1) no one tampers with the intermediate kernel between boot and kexec otherwise the secure boot state is effectively invalidated, and (2) the image that gets kexec'ed is trusted. Remember: you cannot know (2) if you don't have (1). And if someone tampers with the aim of breaking, say, Windows, then someone, e.g. Microsoft, might blacklist the shim. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 8:05 ` David Howells @ 2018-04-04 14:35 ` Andy Lutomirski 2018-04-04 14:44 ` David Howells 2018-04-04 15:43 ` Eric W. Biederman 2 siblings, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-04 14:35 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Jann Horn, Linus Torvalds, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi I've reordered your email to make my email more coherent. > On Apr 4, 2018, at 1:05 AM, David Howells <dhowells@redhat.com> wrote: > > > What we *have* said is that *if* we want to pass the secure boot state across > kexec, then we have to make sure that: > What do you even mean "pass the secure boot state across kexec"? All I can come up with is that you want a kexeced Linux kernel to also be passed a flag saying "I was secure booted" and to enable or disable lockdown accordingly. Let's consider the cases: 1. First kernel is verified (secure boot or otherwise) and locked down. Certainly that lock down needs to enforce that the next kernel in the chain is locked down, otherwise lockdown gets defeated. 2. First kernel is not verified but is locked down. It still needs to enforce that the next kernel is verified and locked down, otherwise lockdown gets defeated. 3. First kernel is verified but not locked down. There's very little point in trying to force the next kernel to be locked down. 4. First kernel is neither verified nor locked down. There's still no point in trying to force the next kernel to be locked down. Isn't the right solution to have a flag saying "force lockdown" that kexec can pass to the child kernel? A locked down parent kernel would refuse to load an unsigned child kernel and would always set that flag. > Andy Lutomirski <luto@kernel.org> wrote: > >> As far as I can tell, what's really going on here is that there's a >> significant contingent here that wants to prevent Linux from >> chainloading something that isn't Linux. > > You have completely the wrong end of the stick. No one has said that or even > implied that. You are alleging dishonesty on our part. I'm alleging that the idea that Linux seems some particular policy to avoid being blacklisted keeps being brought up as a justification for these patches. And, in fact, you bring it up again right here: > > And if someone tampers with the aim of breaking, say, Windows, then someone, > e.g. Microsoft, might blacklist the shim. In other words, if you chainload an intentionally corrupted copy of Windows, you get blacklisted? This sounds awfully like what I said upthread. Is this actually a real concern? Greg seems quite convinced that it isn't. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 8:05 ` David Howells 2018-04-04 14:35 ` Andy Lutomirski @ 2018-04-04 14:44 ` David Howells 2018-04-04 15:43 ` Eric W. Biederman 2 siblings, 0 replies; 116+ messages in thread From: David Howells @ 2018-04-04 14:44 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Andy Lutomirski, Jann Horn, Linus Torvalds, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@amacapital.net> wrote: > > Andy Lutomirski <luto@kernel.org> wrote: > > > >> As far as I can tell, what's really going on here is that there's a > >> significant contingent here that wants to prevent Linux from > >> chainloading something that isn't Linux. > > > > You have completely the wrong end of the stick. No one has said that or > > even implied that. You are alleging dishonesty on our part. > > I'm alleging that the idea that Linux seems some particular policy to > avoid being blacklisted keeps being brought up as a justification for > these patches. No, you were alleging that "[we want] to prevent Linux from chainloading something that isn't Linux.". This is not true - at least, it's not true on my part; I cannot speak for what other people may think privately. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-04 8:05 ` David Howells 2018-04-04 14:35 ` Andy Lutomirski 2018-04-04 14:44 ` David Howells @ 2018-04-04 15:43 ` Eric W. Biederman 2 siblings, 0 replies; 116+ messages in thread From: Eric W. Biederman @ 2018-04-04 15:43 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Jann Horn, Linus Torvalds, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi David Howells <dhowells@redhat.com> writes: > Andy Lutomirski <luto@kernel.org> wrote: > >> As far as I can tell, what's really going on here is that there's a >> significant contingent here that wants to prevent Linux from >> chainloading something that isn't Linux. > > You have completely the wrong end of the stick. No one has said that or even > implied that. You are alleging dishonesty on our part. > > What we *have* said is that *if* we want to pass the secure boot state across > kexec, then we have to make sure that: > > (1) no one tampers with the intermediate kernel between boot and kexec > otherwise the secure boot state is effectively invalidated, and > > (2) the image that gets kexec'ed is trusted. > > Remember: you cannot know (2) if you don't have (1). > > And if someone tampers with the aim of breaking, say, Windows, then someone, > e.g. Microsoft, might blacklist the shim. *Wow* You just denied this isn't about not booting Windows and a few lines later said that is your concern. I was thinking I would have to dig up old archives where I had been told this before, but you just nicely repeated all of the old arguments so I don't see the point. Eric ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:17 ` Matthew Garrett 2018-04-03 23:26 ` Linus Torvalds @ 2018-04-03 23:56 ` David Howells 2018-04-03 23:58 ` Linus Torvalds 1 sibling, 1 reply; 116+ messages in thread From: David Howells @ 2018-04-03 23:56 UTC (permalink / raw) To: Linus Torvalds Cc: dhowells, Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Linus Torvalds <torvalds@linux-foundation.org> wrote: > Be honest now. It wasn't generally users who clamored for it. > ... > If the user actually wanted it, and is asking for it, he can enable it. >From the distributions' point of view, this is a rubbish argument. Most users haven't even given this a moment's thought, aren't even aware of the issues, don't even know to ask and, for them, it makes no difference. They trust their distribution to deal with stuff they don't know about. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:56 ` David Howells @ 2018-04-03 23:58 ` Linus Torvalds 0 siblings, 0 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:58 UTC (permalink / raw) To: David Howells Cc: Matthew Garrett, Andrew Lutomirski, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:56 PM, David Howells <dhowells@redhat.com> wrote: => > Most users haven't even given this a moment's thought, aren't even aware of > the issues, don't even know to ask and, for them, it makes no difference. > They trust their distribution to deal with stuff they don't know about. Right. Like perhaps trusting the distribution to just enable all those security measures _regaredless_ of whether they booted in using secure boot or not? See? If lockdown breaks something, the distro would need to fix it regardless of secure boot. So why is the enablement dependent on it again? I'm not arguing "lockdown shouldn't be on". I'm arguing "lockdown being on or off has _nothing_ to do with whether the machine was booted in EFI mode with secure boot or not". You don't seem to get it. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:39 ` Andy Lutomirski 2018-04-03 22:46 ` Linus Torvalds @ 2018-04-03 23:39 ` David Howells 2018-04-03 23:48 ` Andy Lutomirski 2018-04-08 8:23 ` Pavel Machek 1 sibling, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-03 23:39 UTC (permalink / raw) To: Linus Torvalds Cc: dhowells, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Linus Torvalds <torvalds@linux-foundation.org> wrote: > The same thing is true of some lockdown patch. Maybe it's a good thing > in general. But whether it's a good thing is _entirely_ independent of > any secure boot issue. I can see using secure boot without it, but I > can very much also see using lockdown without secure boot. > > The two things are simply entirely orthogonal. They have _zero_ > overlap. I'm not seeing why they'd be linked at all in any way. I'm not sure I agree. Here's my reasoning: (1) Lockdown mode really needs to activated during kernel boot, before userspace has a chance to run, otherwise there's a window of opportunity in which the kernel *isn't* locked down. (2) If the kernel isn't booted in secure boot mode, then there's the opportunity to tamper before the kernel even starts booting. (3) There doesn't seem any point in booting in secure boot mode if you don't protect the running kernel image against tampering. What does it mean to be in "secure boot mode" in that case? If the kernel can be tampered with, it would seem to be, by definition, insecure. (4) You can't validly promise the next OS you kexec that *it* is started in secure boot mode if you don't stop your image from being tampered with. Note that this doesn't prevent a compromised kernel from lying to the next OS. (5) Tampering with a running kernel can be achieved in a variety of ways: loading of arbitrary modules, loading of modified firmware, direct access to devices that can effect DMA, writing to /dev/mem, ... (6) We need to be able to load modules and firmware, but these can be signed, hashed or measured so we have some idea of their provenance - but signing can be worked around if, say, /dev/mem is writable. (7) If you told the BIOS[*] that you want to be in secure boot mode, then the kernel should honour that and try to prevent tampering with the image. (8) Turning lockdown mode on if the kernel is booted in secure boot seems to be the way to achieve this. (9) BIOS vendors can blacklist any of the components - say the SHIM - to prevent an insecure kernel from being used to compromise and kexec another OS. Note that I've provided a kernel command line parameter that will turn lockdown mode on arbitrarily - but that can be turned off by editing the parameters in grub.cfg, say. David [*] Yeah, I know, this is an x86-centric view. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:39 ` David Howells @ 2018-04-03 23:48 ` Andy Lutomirski 2018-04-08 8:23 ` Pavel Machek 1 sibling, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 23:48 UTC (permalink / raw) To: David Howells Cc: Linus Torvalds, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:39 PM, David Howells <dhowells@redhat.com> wrote: > Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> The same thing is true of some lockdown patch. Maybe it's a good thing >> in general. But whether it's a good thing is _entirely_ independent of >> any secure boot issue. I can see using secure boot without it, but I >> can very much also see using lockdown without secure boot. >> >> The two things are simply entirely orthogonal. They have _zero_ >> overlap. I'm not seeing why they'd be linked at all in any way. > > I'm not sure I agree. Here's my reasoning: > > (1) Lockdown mode really needs to activated during kernel boot, before > userspace has a chance to run, otherwise there's a window of opportunity > in which the kernel *isn't* locked down. That's simply not true. A sensible verified boot chain (a la Chrome OS) is likely to load, as one verified chunk, a kernel and initramfs. Then initramfs can flip on lockdown all by itself before it enables networking or any other attack vectors. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:39 ` David Howells 2018-04-03 23:48 ` Andy Lutomirski @ 2018-04-08 8:23 ` Pavel Machek 1 sibling, 0 replies; 116+ messages in thread From: Pavel Machek @ 2018-04-08 8:23 UTC (permalink / raw) To: David Howells Cc: Linus Torvalds, Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi [-- Attachment #1: Type: text/plain, Size: 1736 bytes --] On Wed 2018-04-04 00:39:05, David Howells wrote: > Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > The same thing is true of some lockdown patch. Maybe it's a good thing > > in general. But whether it's a good thing is _entirely_ independent of > > any secure boot issue. I can see using secure boot without it, but I > > can very much also see using lockdown without secure boot. > > > > The two things are simply entirely orthogonal. They have _zero_ > > overlap. I'm not seeing why they'd be linked at all in any way. > > I'm not sure I agree. Here's my reasoning: > > (1) Lockdown mode really needs to activated during kernel boot, before > userspace has a chance to run, otherwise there's a window of opportunity > in which the kernel *isn't* locked down. > > (2) If the kernel isn't booted in secure boot mode, then there's the > opportunity to tamper before the kernel even starts booting. > > (3) There doesn't seem any point in booting in secure boot mode if you don't > protect the running kernel image against tampering. What does it mean to > be in "secure boot mode" in that case? If the kernel can be tampered > with, it would seem to be, by definition, insecure. This one is not true, either. If kernel does "printk(KERN_CRIT "loading unsigned module"); mdelay(10000);", it is useful for secure boot and provides way to owner to play. Nokia N9 / N950 uses this kind of "security" for example. It is rather annoying but better than not being able to run custom kernels at all. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 22:32 ` David Howells 2018-04-03 22:39 ` Andy Lutomirski @ 2018-04-03 23:12 ` David Howells 2018-04-03 23:27 ` Linus Torvalds 2018-04-03 23:42 ` Andy Lutomirski 1 sibling, 2 replies; 116+ messages in thread From: David Howells @ 2018-04-03 23:12 UTC (permalink / raw) To: Andy Lutomirski Cc: dhowells, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi Andy Lutomirski <luto@kernel.org> wrote: > I'm having a very, very hard time coming up with a scenario where I > can "trust" something if an attacker can get root but can't modify the > running kernel image but I can't "trust" something if the attacker > can [modify the running kernel image]. (I think the above is what you meant) Let's go at this a different way. How do you decide you can trust something in this context? You compare it to something. Signing it, keeping a hash whitelist, IMA - these are all ways of comparing something. Do you agree with that? However, the comparison can be subverted if the running kernel image (I might be better saying running kernel state here since I'm not talking about the source bzImage file) can be modified arbitrarily by userspace, either by modifying the data against which the comparison is made - e.g. the public key set or the hash list - or by modifying the code that makes the comparison. /dev/mem, direct access to DMA, bpf, etc. all provide ways of modifying the kernel image arbitrarily, which leads me to this: > I *don't* buy into the party line about why signed modules should be needed > for Secure Boot. Modules are just another way of modifying the kernel image. If I can just create an arbitrary module and load it, then I can modify the kernel image from within the module. Locking down modules by signing, hashing or IMA practically prevents the loading of arbitrarily constructed modules and only permits modules from a set that the provider of the modules somewhat trusts. What use is secure boot if processes run as root can subvert your kernel? > > There's no point bothering with UID/GID checking either. > > Give me a break. There's a *huge* difference between a system where > only root can load unsigned modules and a system where anyone can load > unsigned modules. I don't think we've ever advocated letting just anyone load a module. But my point is that if you can modify the running kernel, you can nullify all security checks, including UID/GID checks. > > However, if /dev/mem can be read, any root process can extract the session > > key for your disk. > > Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise. True - for now - and they can also access the mounted filesystem. But if they get their hands on your powered-off computer, no, they can't. > But I don't think the upstream kernel should apply a patch that ties any of > this to Secure Boot without a genuine technical reason why it makes sense. Because unless you turn lockdown on during kernel boot, there exists a window of opportunity where the kernel isn't locked down and can be accessed, thereby obviating the fact that you started in Secure Boot mode. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:12 ` David Howells @ 2018-04-03 23:27 ` Linus Torvalds 2018-04-03 23:42 ` Andy Lutomirski 1 sibling, 0 replies; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 23:27 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:12 PM, David Howells <dhowells@redhat.com> wrote: > > What use is secure boot if processes run as root can subvert your kernel? Stop this idiocy. The above has now been answered multiple times, several different ways. The "point" of secure boot may be that you had no choice, or there was no point at all, it just came that way. Or the "point" of secure boot may be that you don't trust anybody else than yourself, but once you've booted you do trust what you booted. But the *real* point is that this has nothing what-so-ever to do with secure boot. You may want (or not want) lockdown independently of it. Don't tie magic boot issues with kernel runtime behavior. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 23:12 ` David Howells 2018-04-03 23:27 ` Linus Torvalds @ 2018-04-03 23:42 ` Andy Lutomirski 1 sibling, 0 replies; 116+ messages in thread From: Andy Lutomirski @ 2018-04-03 23:42 UTC (permalink / raw) To: David Howells Cc: Andy Lutomirski, Matthew Garrett, Ard Biesheuvel, James Morris, Alan Cox, Linus Torvalds, Greg Kroah-Hartman, Linux Kernel Mailing List, Justin Forbes, linux-man, joeyli, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 4:12 PM, David Howells <dhowells@redhat.com> wrote: > Andy Lutomirski <luto@kernel.org> wrote: > >> I'm having a very, very hard time coming up with a scenario where I >> can "trust" something if an attacker can get root but can't modify the >> running kernel image but I can't "trust" something if the attacker >> can [modify the running kernel image]. > > (I think the above is what you meant) > > Let's go at this a different way. How do you decide you can trust something > in this context? You compare it to something. Signing it, keeping a hash > whitelist, IMA - these are all ways of comparing something. Do you agree with > that? I trust or distrust a system as a whole. I don't make that decision by comparing it to anything. I make it by evaluating how the system works and deciding whether it's trustworthy. > > What use is secure boot if processes run as root can subvert your kernel? > Secure boot serves several purposes: 1. Anti-competitive purposes. It's intentionally difficult to run non-Windows OSes on Windows ARM machines, for example. 2. Allowing me to use a stock UEFI machine to have a verified boot chain. The latter has nothing whatsoever to do with CPL0. The former, however, does. If I could easily write some Windows program to run CPL0 code, then I could chainload Linux using the Windows image, and I've subverted the purpose. Cynical? Yes. >> > There's no point bothering with UID/GID checking either. >> >> Give me a break. There's a *huge* difference between a system where >> only root can load unsigned modules and a system where anyone can load >> unsigned modules. > > I don't think we've ever advocated letting just anyone load a module. > > But my point is that if you can modify the running kernel, you can nullify all > security checks, including UID/GID checks. > >> > However, if /dev/mem can be read, any root process can extract the session >> > key for your disk. >> >> Any root process can read /dev/mapper/plaintext_disk, lockdown or otherwise. > > True - for now - and they can also access the mounted filesystem. But if they > get their hands on your powered-off computer, no, they can't. This is, IMO, a silly argument. You're saying that some bad guy has managed to run code as root on my laptop. Then, next week, the bad guy steals my laptop while it's powered off, and Lockdown is supposed to protect me against that bad guy. If this happens, I've already lost completely, lockdown or no. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 16:29 ` Matthew Garrett 2018-04-03 16:45 ` Andy Lutomirski 2018-04-03 17:16 ` David Howells @ 2018-04-03 20:53 ` Linus Torvalds 2018-04-03 20:54 ` Matthew Garrett 2 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 20:53 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: >> Can you explain that much more clearly? I'm asking why booting via >> UEFI Secure Boot should enable lockdown, and I don't see what this has >> to do with kexec. And "someone blacklist[ing] your key in the >> bootloader" sounds like a political issue, not a technical issue. > > A kernel that allows users arbitrary access to ring 0 is just an > overfeatured bootloader. Why would you want secure boot in that case? .. maybe you don't *want* secure boot, but it's been pushed in your face by people with an agenda? Seriously. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 20:53 ` Linus Torvalds @ 2018-04-03 20:54 ` Matthew Garrett 2018-04-03 21:01 ` Linus Torvalds 0 siblings, 1 reply; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 20:54 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 1:53 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@google.com> wrote: > > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote: > >> Can you explain that much more clearly? I'm asking why booting via > >> UEFI Secure Boot should enable lockdown, and I don't see what this has > >> to do with kexec. And "someone blacklist[ing] your key in the > >> bootloader" sounds like a political issue, not a technical issue. > > > > A kernel that allows users arbitrary access to ring 0 is just an > > overfeatured bootloader. Why would you want secure boot in that case? > .. maybe you don't *want* secure boot, but it's been pushed in your > face by people with an agenda? Then turn it off, or build a self-signed kernel that doesn't do this? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 20:54 ` Matthew Garrett @ 2018-04-03 21:01 ` Linus Torvalds 2018-04-03 21:08 ` Matthew Garrett 0 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 21:01 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mjg59@google.com> wrote: > >> .. maybe you don't *want* secure boot, but it's been pushed in your >> face by people with an agenda? > > Then turn it off, or build a self-signed kernel that doesn't do this? Umm. So you asked a question, and then when you got an answer you said "don't do that then". The fact is, some hardware pushes secure boot pretty hard. That has *nothing* to do with some "lockdown" mode. Why do you conflate the two? That was the original question. You replied with another question. People answered yours. NOW ANSWER THE ORIGINAL QUESTION, DAMMIT. Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:01 ` Linus Torvalds @ 2018-04-03 21:08 ` Matthew Garrett 2018-04-03 21:21 ` Al Viro ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 21:08 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mjg59@google.com> wrote: > > > >> .. maybe you don't *want* secure boot, but it's been pushed in your > >> face by people with an agenda? > > > > Then turn it off, or build a self-signed kernel that doesn't do this? > Umm. So you asked a question, and then when you got an answer you said > "don't do that then". > The fact is, some hardware pushes secure boot pretty hard. That has > *nothing* to do with some "lockdown" mode. Secure Boot ensures that the firmware will only load signed bootloaders. If a signed bootloader loads a kernel that's effectively an unsigned bootloader, there's no point in using Secure Boot - you should just turn it off instead, because it's not giving you any meaningful security. Andy's example gives a scenario where by constraining your *userland* sufficiently you can get close to having the same guarantees, but that involves you having a read-only filesystem and takes you even further away from having a general purpose computer. If you don't want Secure Boot, turn it off. If you want Secure Boot, use a kernel that behaves in a way that actually increases your security. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:08 ` Matthew Garrett @ 2018-04-03 21:21 ` Al Viro 2018-04-03 21:37 ` Matthew Garrett 2018-04-03 21:26 ` Linus Torvalds 2018-04-08 8:10 ` Pavel Machek 2 siblings, 1 reply; 116+ messages in thread From: Al Viro @ 2018-04-03 21:21 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 03, 2018 at 09:08:54PM +0000, Matthew Garrett wrote: > > The fact is, some hardware pushes secure boot pretty hard. That has > > *nothing* to do with some "lockdown" mode. > > Secure Boot ensures that the firmware will only load signed bootloaders. If > a signed bootloader loads a kernel that's effectively an unsigned > bootloader, there's no point in using Secure Boot - you should just turn it > off instead, because it's not giving you any meaningful security. Andy's > example gives a scenario where by constraining your *userland* sufficiently > you can get close to having the same guarantees, but that involves you > having a read-only filesystem and takes you even further away from having a > general purpose computer. > > If you don't want Secure Boot, turn it off. If you want Secure Boot, use a > kernel that behaves in a way that actually increases your security. That assumes you *can* turn that shit off. On the hardware where manufacturer has installed firmware that doesn't allow that SB is a misfeature that has to be worked around. Making that harder might improve the value of SB to said manufacturers, but what's the benefit for everybody else? ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:21 ` Al Viro @ 2018-04-03 21:37 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 21:37 UTC (permalink / raw) To: Alexander Viro Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 2:21 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > On Tue, Apr 03, 2018 at 09:08:54PM +0000, Matthew Garrett wrote: > > If you don't want Secure Boot, turn it off. If you want Secure Boot, use a > > kernel that behaves in a way that actually increases your security. > That assumes you *can* turn that shit off. On the hardware where manufacturer > has installed firmware that doesn't allow that SB is a misfeature that has > to be worked around. Making that harder might improve the value of SB to > said manufacturers, but what's the benefit for everybody else? This is why Shim has support for its own key database, as well as allowing you to disable further signature validation. If the hardware supports third party code at all, you can just use Shim to sidestep any unreasonable restrictions the vendor has imposed. (This doesn't help with systems that don't support third party code at all, but this patchset does nothing to make that worse - that hardware wouldn't boot your own kernel before this patchset, and it won't afterwards either) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:08 ` Matthew Garrett 2018-04-03 21:21 ` Al Viro @ 2018-04-03 21:26 ` Linus Torvalds 2018-04-03 21:32 ` Matthew Garrett 2018-04-08 8:10 ` Pavel Machek 2 siblings, 1 reply; 116+ messages in thread From: Linus Torvalds @ 2018-04-03 21:26 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Lutomirski, David Howells, Ard Biesheuvel, James Morris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, Linux API, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett <mjg59@google.com> wrote: > > Secure Boot ensures that the firmware will only load signed bootloaders. If > a signed bootloader loads a kernel that's effectively an unsigned > bootloader, there's no point in using Secure Boot Bullshit. I may want to know that I'm running *my* kernel, but once that is the case, I trust it. In fact, I tend to trust it more than some random vendor key. You should too. Your whole argument is FUNDAMENTALLY garbage. It's the Disney kind of garbage. It was garbage back then, and it's garbage now. It is also garbage for a simple technical reason: secure boot can be hard to turn off. Sometimes "turn off" means "you just have to add your own keys". Yes, on x86 hardware at least at some point MS actually had the rule that it has to be something you can turn off. That rule is apparently not true on ARM, though. Seriously. You sound like you're parroting some party line, not like you are answering the actual question. So again: why do you conflate the two issues? If you want lockdown, fine, enable it. But what the F*CK does that have to do with whether you had secure boot or not? Linus ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:26 ` Linus Torvalds @ 2018-04-03 21:32 ` Matthew Garrett 0 siblings, 0 replies; 116+ messages in thread From: Matthew Garrett @ 2018-04-03 21:32 UTC (permalink / raw) To: Linus Torvalds Cc: luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi On Tue, Apr 3, 2018 at 2:26 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Tue, Apr 3, 2018 at 2:08 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > Secure Boot ensures that the firmware will only load signed bootloaders. If > > a signed bootloader loads a kernel that's effectively an unsigned > > bootloader, there's no point in using Secure Boot > Bullshit. > I may want to know that I'm running *my* kernel, but once that is the > case, I trust it. If you don't believe that your self-signed kernel is going to be a threat against your security model then great! Don't turn this on when you build it. But if you built a kernel that didn't have this lockdown functionality and got it signed with, say, Red Hat's signing keys, anyone could take Red Hat's bootloader chain and that kernel and subvert the Secure Boot chain on any machine that trusts the third party signing key (ie, basically all of them) > Yes, on x86 hardware at least at some point MS actually had the rule > that it has to be something you can turn off. That rule is apparently > not true on ARM, though. Correct - there's no requirement that it be something you can disable on ARM, but since Microsoft won't sign any third-party code for ARM anyway it makes no difference to this discussion. > If you want lockdown, fine, enable it. But what the F*CK does that > have to do with whether you had secure boot or not? Because a kernel signed with a generally trusted key that doesn't implement any lockdown functionality is effectively a bootloader that will load unsigned material on most machines on the market, which reduces the security of users running those machines with Secure Boot enabled. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 21:08 ` Matthew Garrett 2018-04-03 21:21 ` Al Viro 2018-04-03 21:26 ` Linus Torvalds @ 2018-04-08 8:10 ` Pavel Machek 2 siblings, 0 replies; 116+ messages in thread From: Pavel Machek @ 2018-04-08 8:10 UTC (permalink / raw) To: Matthew Garrett Cc: Linus Torvalds, luto, David Howells, Ard Biesheuvel, jmorris, Alan Cox, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, jlee, LSM List, linux-api, Kees Cook, linux-efi [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] On Tue 2018-04-03 21:08:54, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 2:01 PM Linus Torvalds > <torvalds@linux-foundation.org> > wrote: > > > On Tue, Apr 3, 2018 at 1:54 PM, Matthew Garrett <mjg59@google.com> wrote: > > > > > >> .. maybe you don't *want* secure boot, but it's been pushed in your > > >> face by people with an agenda? > > > > > > Then turn it off, or build a self-signed kernel that doesn't do this? > > > Umm. So you asked a question, and then when you got an answer you said > > "don't do that then". > > > The fact is, some hardware pushes secure boot pretty hard. That has > > *nothing* to do with some "lockdown" mode. > > Secure Boot ensures that the firmware will only load signed bootloaders. If > a signed bootloader loads a kernel that's effectively an unsigned > bootloader, there's no point in using Secure Boot - you should just turn it > off instead, because it's not giving you any meaningful > security. Andy's Not true. I have kernel with printk() enabled. Yes, once userland is started, you can boot another kernel, maybe. Maybe my kernel is locked down with exception of kexec, and it does printk(KERN_CRIT "kexecing") followed by mdelay(5000). That's pretty good security. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells 2018-03-31 0:46 ` James Morris @ 2018-03-31 10:20 ` David Howells 2018-04-03 13:25 ` Ard Biesheuvel 2018-11-21 12:05 ` [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series Vasily Gorbik 2 siblings, 1 reply; 116+ messages in thread From: David Howells @ 2018-03-31 10:20 UTC (permalink / raw) To: James Morris Cc: dhowells, gnomes, linux-efi, mjg59, gregkh, linux-kernel, jforbes, linux-man, jlee, linux-security-module James Morris <jmorris@namei.org> wrote: > Are there any known coverage gaps now? I've covered all the ones I know about. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-03-31 10:20 ` David Howells @ 2018-04-03 13:25 ` Ard Biesheuvel 2018-04-03 21:48 ` James Morris 2018-04-05 17:53 ` Alan Cox 0 siblings, 2 replies; 116+ messages in thread From: Ard Biesheuvel @ 2018-04-03 13:25 UTC (permalink / raw) To: David Howells, Andy Lutomirski, Kees Cook Cc: James Morris, One Thousand Gnomes, linux-efi, Matthew Garrett, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, joeyli, linux-security-module (+ Andy and Kees so they can respond to the thread) On 31 March 2018 at 12:20, David Howells <dhowells@redhat.com> wrote: > James Morris <jmorris@namei.org> wrote: > >> Are there any known coverage gaps now? > > I've covered all the ones I know about. > Andy (and Kees) responded to this without keeping all the cc's. Given that I share Andy's concern wrt the general nature of these patches, I will reiterate them here. First of all, in my experience, when introducing any kind of 'secure' mode, people will immediately assume that everything they use the system for will be more secure going forward, and so they are more likely to let their guard down, resulting in a less secure situation than we started out with. So I already argued for calling this a 'lockdown policy' which is a clearly communicated as a best effort attempt to make the system more robust against inadvertent modifications, and documenting/logging clearly what it actually *means*. The latter is especially important because many of these things are arch specific, and need to be implemented for each arch individually in order to take effect on them. Also, v4.17 lockdown will most likely be different from v4.18 lockdown. Furthermore, there is a fundamental deviation from common security sense here, where things like command line parameters and other lockdown specific tunables are blacklisted rather than whitelisted, and so rather than locking everything down and re-enabling only once what needs to be re-enabled for the system to work, we are now forever going to have to track a moving target, where it is someone's job to ensure that incoming changes don't regress lockdown mode on any of the architectures it supports. If the distros are shipping their kernels with these patches applied to adhere to some kind of requirements imposed by MicroSoft in order for them to be willing to sign shim images, can we please involve those into the discussion as well? It seems to me that this is a solution without a problem statement, and I would like to fully understand the problem before reasoning about the solution. -- Ard. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 13:25 ` Ard Biesheuvel @ 2018-04-03 21:48 ` James Morris 2018-04-05 17:53 ` Alan Cox 1 sibling, 0 replies; 116+ messages in thread From: James Morris @ 2018-04-03 21:48 UTC (permalink / raw) To: Ard Biesheuvel Cc: David Howells, Andy Lutomirski, Kees Cook, One Thousand Gnomes, linux-efi, Matthew Garrett, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, joeyli, linux-security-module On Tue, 3 Apr 2018, Ard Biesheuvel wrote: > [snip] Thanks for the input -- there are obviously still issues to be resolved. I'll now not be pushing these to Linus for v4.17. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: [GIT PULL] Kernel lockdown for secure boot 2018-04-03 13:25 ` Ard Biesheuvel 2018-04-03 21:48 ` James Morris @ 2018-04-05 17:53 ` Alan Cox 1 sibling, 0 replies; 116+ messages in thread From: Alan Cox @ 2018-04-05 17:53 UTC (permalink / raw) To: Ard Biesheuvel Cc: David Howells, Andy Lutomirski, Kees Cook, James Morris, linux-efi, Matthew Garrett, Greg Kroah-Hartman, Linux Kernel Mailing List, jforbes, linux-man, joeyli, linux-security-module > Furthermore, there is a fundamental deviation from common security > sense here, where things like command line parameters and other > lockdown specific tunables are blacklisted rather than whitelisted, I've been complaining about this from the start but it appears to be a write only authorship process going on. Alan ^ permalink raw reply [flat|nested] 116+ messages in thread
* [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series 2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells 2018-03-31 0:46 ` James Morris 2018-03-31 10:20 ` David Howells @ 2018-11-21 12:05 ` Vasily Gorbik 2018-11-21 12:05 ` [PATCH next-lockdown 1/1] debugfs: avoid EPERM when no open file operation defined Vasily Gorbik 2 siblings, 1 reply; 116+ messages in thread From: Vasily Gorbik @ 2018-11-21 12:05 UTC (permalink / raw) To: David Howells, James Morris Cc: Martin Schwidefsky, Greg Kroah-Hartman, linux-kernel, linux-security-module Not sure whom to offer the fix, since 'Kernel lockdown for secure boot' in not upstream, but it has been picked by fedora and ubuntu. And I see it in next-lockdown branch of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git So, in addition to (prior to) opening bug reports to distributions I'm sending this patch hoping to reach its origin from where distributions had picked it. Vasily Gorbik (1): debugfs: avoid EPERM when no open file operation defined fs/debugfs/file.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.18.0.13.gd42ae10 ^ permalink raw reply [flat|nested] 116+ messages in thread
* [PATCH next-lockdown 1/1] debugfs: avoid EPERM when no open file operation defined 2018-11-21 12:05 ` [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series Vasily Gorbik @ 2018-11-21 12:05 ` Vasily Gorbik 0 siblings, 0 replies; 116+ messages in thread From: Vasily Gorbik @ 2018-11-21 12:05 UTC (permalink / raw) To: David Howells, James Morris Cc: Martin Schwidefsky, Greg Kroah-Hartman, linux-kernel, linux-security-module With "debugfs: Restrict debugfs when the kernel is locked down" return code "r" is unconditionally set to -EPERM, which stays like that until function return if no "open" file operation defined, effectivelly resulting in "Operation not permitted" for all such files despite kernel lock down status or CONFIG_LOCK_DOWN_KERNEL being enabled. In particular this breaks 2 debugfs files on s390: /sys/kernel/debug/s390_hypfs/diag_304 /sys/kernel/debug/s390_hypfs/diag_204 To address that set EPERM return code only when debugfs_is_locked_down returns true. Fixes: 3fc322605158 ("debugfs: Restrict debugfs when the kernel is locked down") Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> --- fs/debugfs/file.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c index 51cb894c21f2..89c86faaa02a 100644 --- a/fs/debugfs/file.c +++ b/fs/debugfs/file.c @@ -167,9 +167,10 @@ static int open_proxy_open(struct inode *inode, struct file *filp) real_fops = debugfs_real_fops(filp); - r = -EPERM; - if (debugfs_is_locked_down(inode, filp, real_fops)) + if (debugfs_is_locked_down(inode, filp, real_fops)) { + r = -EPERM; goto out; + } real_fops = fops_get(real_fops); if (!real_fops) { @@ -296,9 +297,10 @@ static int full_proxy_open(struct inode *inode, struct file *filp) return r == -EIO ? -ENOENT : r; real_fops = debugfs_real_fops(filp); - r = -EPERM; - if (debugfs_is_locked_down(inode, filp, real_fops)) + if (debugfs_is_locked_down(inode, filp, real_fops)) { + r = -EPERM; goto out; + } real_fops = fops_get(real_fops); if (!real_fops) { -- 2.18.0.13.gd42ae10 ^ permalink raw reply related [flat|nested] 116+ messages in thread
end of thread, other threads:[~2018-11-21 12:05 UTC | newest] Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-30 23:29 [GIT PULL] Kernel lockdown for secure boot David Howells 2018-03-31 0:46 ` James Morris 2018-04-03 0:37 ` Andy Lutomirski 2018-04-03 0:59 ` Kees Cook 2018-04-03 1:47 ` Andy Lutomirski 2018-04-03 7:06 ` David Howells 2018-04-03 15:11 ` Andy Lutomirski 2018-04-03 15:41 ` Alexei Starovoitov 2018-04-03 16:26 ` Andy Lutomirski 2018-04-03 16:29 ` Matthew Garrett 2018-04-03 16:45 ` Andy Lutomirski 2018-04-03 18:45 ` Kees Cook 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:07 ` Kees Cook 2018-04-03 19:29 ` Matthew Garrett 2018-04-03 21:51 ` Andy Lutomirski 2018-04-04 18:42 ` Peter Jones 2018-04-04 20:01 ` Thomas Gleixner 2018-04-04 20:18 ` Matthew Garrett 2018-04-05 18:47 ` Andy Lutomirski 2018-04-06 4:42 ` Peter Dolding 2018-04-03 17:16 ` David Howells 2018-04-03 19:01 ` Andy Lutomirski 2018-04-03 19:49 ` David Howells 2018-04-03 21:58 ` Andy Lutomirski 2018-04-03 22:32 ` David Howells 2018-04-03 22:39 ` Andy Lutomirski 2018-04-03 22:46 ` Linus Torvalds 2018-04-03 22:51 ` Matthew Garrett 2018-04-03 22:53 ` Andy Lutomirski 2018-04-03 23:08 ` Justin Forbes 2018-04-03 23:09 ` Matthew Garrett 2018-04-03 23:08 ` Linus Torvalds 2018-04-03 23:10 ` Linus Torvalds 2018-04-03 23:17 ` Matthew Garrett 2018-04-03 23:26 ` Linus Torvalds 2018-04-03 23:39 ` Linus Torvalds 2018-04-03 23:47 ` Matthew Garrett 2018-04-04 0:02 ` Linus Torvalds 2018-04-04 0:04 ` Matthew Garrett 2018-04-04 0:08 ` Linus Torvalds 2018-04-04 0:12 ` Matthew Garrett 2018-04-05 14:58 ` Alan Cox 2018-04-04 0:22 ` David Howells 2018-04-05 17:59 ` Alan Cox 2018-04-05 18:03 ` Matthew Garrett 2018-04-03 23:45 ` Matthew Garrett 2018-04-03 23:55 ` Linus Torvalds 2018-04-03 23:59 ` Matthew Garrett 2018-04-04 0:06 ` Linus Torvalds 2018-04-04 0:10 ` Matthew Garrett 2018-04-04 0:15 ` Linus Torvalds 2018-04-04 0:16 ` Matthew Garrett 2018-04-04 0:18 ` Andy Lutomirski 2018-04-04 0:19 ` Matthew Garrett 2018-04-04 9:04 ` Greg Kroah-Hartman 2018-04-04 0:25 ` Linus Torvalds 2018-04-04 0:33 ` Linus Torvalds 2018-04-04 0:46 ` Matthew Garrett 2018-04-04 0:56 ` Linus Torvalds 2018-04-04 1:13 ` Matthew Garrett 2018-04-04 1:43 ` Linus Torvalds 2018-04-04 4:30 ` Matthew Garrett 2018-04-04 12:57 ` Theodore Y. Ts'o 2018-04-04 13:02 ` Greg Kroah-Hartman 2018-04-04 13:34 ` Theodore Y. Ts'o 2018-04-04 13:57 ` Greg Kroah-Hartman 2018-04-04 13:29 ` Mike Galbraith 2018-04-04 16:20 ` Matthew Garrett 2018-04-08 22:00 ` Pavel Machek 2018-04-04 13:33 ` David Howells 2018-04-04 13:52 ` Theodore Y. Ts'o 2018-04-04 16:22 ` Matthew Garrett 2018-04-04 16:39 ` Andy Lutomirski 2018-04-04 16:42 ` Matthew Garrett 2018-04-04 16:46 ` Justin Forbes 2018-04-05 0:05 ` Peter Dolding 2018-04-05 0:20 ` Matthew Garrett 2018-04-04 13:57 ` David Howells 2018-04-04 16:09 ` Linus Torvalds 2018-04-04 16:17 ` Matthew Garrett 2018-04-04 6:56 ` Peter Dolding 2018-04-04 16:26 ` Matthew Garrett 2018-04-05 1:28 ` Peter Dolding 2018-04-04 1:30 ` Justin Forbes 2018-04-04 1:58 ` Linus Torvalds 2018-04-04 1:36 ` Justin Forbes 2018-04-04 0:17 ` Jann Horn 2018-04-04 0:23 ` Andy Lutomirski 2018-04-04 8:05 ` David Howells 2018-04-04 14:35 ` Andy Lutomirski 2018-04-04 14:44 ` David Howells 2018-04-04 15:43 ` Eric W. Biederman 2018-04-03 23:56 ` David Howells 2018-04-03 23:58 ` Linus Torvalds 2018-04-03 23:39 ` David Howells 2018-04-03 23:48 ` Andy Lutomirski 2018-04-08 8:23 ` Pavel Machek 2018-04-03 23:12 ` David Howells 2018-04-03 23:27 ` Linus Torvalds 2018-04-03 23:42 ` Andy Lutomirski 2018-04-03 20:53 ` Linus Torvalds 2018-04-03 20:54 ` Matthew Garrett 2018-04-03 21:01 ` Linus Torvalds 2018-04-03 21:08 ` Matthew Garrett 2018-04-03 21:21 ` Al Viro 2018-04-03 21:37 ` Matthew Garrett 2018-04-03 21:26 ` Linus Torvalds 2018-04-03 21:32 ` Matthew Garrett 2018-04-08 8:10 ` Pavel Machek 2018-03-31 10:20 ` David Howells 2018-04-03 13:25 ` Ard Biesheuvel 2018-04-03 21:48 ` James Morris 2018-04-05 17:53 ` Alan Cox 2018-11-21 12:05 ` [PATCH next-lockdown 0/1] debugfs EPERM fix for 'Kernel lockdown for secure boot' patch series Vasily Gorbik 2018-11-21 12:05 ` [PATCH next-lockdown 1/1] debugfs: avoid EPERM when no open file operation defined Vasily Gorbik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).