[RFC PATCH 29/68] vfs: Convert efivarfs to use the new mount API

. Signed-off-by: David Howells cc: Matthew Garrett cc: Jeremy Kerr cc: Ard Biesheuvel cc: linux-efi@vger.kernel.org --- fs/efivarfs/super.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 5b68e4294faa

[PATCH 26/38] vfs: Convert efivarfs to fs_context

Signed-off-by: David Howells cc: Matthew Garrett cc: Jeremy Kerr cc: Ard Biesheuvel cc: linux-efi@vger.kernel.org --- fs/efivarfs/super.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/fs/efivarfs/super.c b/fs/efivarfs/super.c index 5b68e4294faa

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

Jann Horn wrote: > > Uh, no. bpf, for example, can be used to modify kernel memory. > > I'm pretty sure bpf isn't supposed to be able to modify arbitrary > kernel memory. AFAIU if you can use BPF to write to arbitrary kernel > memory, that's a bug; with CAP_SYS_ADMIN, you can

Re: An actual suggestion (Re: [GIT PULL] Kernel lockdown for secure boot)

Andy Lutomirski wrote: > Since this thread has devolved horribly, I'm going to propose a solution. > > 1. Split the "lockdown" state into three levels: (please don't > bikeshed about the names right now.) > > LOCKDOWN_NONE: normal behavior > > LOCKDOWN_PROTECT_INTEGREITY:

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski wrote: > > Andy Lutomirski 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

Re: [GIT PULL] Kernel lockdown for secure boot

Theodore Y. Ts'o 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

Re: [GIT PULL] Kernel lockdown for secure boot

Theodore Y. Ts'o 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

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski 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

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds 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

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds 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

Re: [GIT PULL] Kernel lockdown for secure boot

Linus Torvalds 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

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski 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

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski 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

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski 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. >

Re: [GIT PULL] Kernel lockdown for secure boot

Andy Lutomirski 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 -- To

Re: [GIT PULL] Kernel lockdown for secure boot

James Morris wrote: > Are there any known coverage gaps now? I've covered all the ones I know about. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at

[GIT PULL] Kernel lockdown for secure boot

Copyright (C) 2017 Red Hat, Inc. All Rights Reserved. .\" Written by David Howells (dhowe...@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 L

Re: linux-next: UEFI Secure boot lockdown patchset

I forgot to include the branch URL: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down Thanks for spotting that, Ard! David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to

linux-next: UEFI Secure boot lockdown patchset

for which I've written a manpage that is referenced in the message (see attached). David .\" .\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved. .\" Written by David Howells (dhowe...@redhat.com) .\" .\" %%%LICENSE_START(GPLv2+_SW_ONEPARA) .\" This program is free

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

David Howells <dhowe...@redhat.com> wrote: > I'm intending on inserting the attached patch before this one. And replacing this patch with the attached. David --- commit ed0424c531d7dd25adebdec0ee6a78a5784f207a Author: David Howells <dhowe...@redhat.com> Date: Thu Feb 22 14:0

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

I'm intending on inserting the attached patch before this one. David --- commit 87a39b258eca2e15884ee90c3fcd5758d6057b17 Author: David Howells <dhowe...@redhat.com> Date: Thu Feb 22 13:42:04 2018 + kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG

Re: [PATCH 04/30] Enforce module signatures if the kernel is locked down

I'm considering folding the attached changes into this patch. It adjusts the errors generated: (1) If there's no signature (ENODATA) or we can't check it (ENOPKG, ENOKEY), then: (a) If signatures are enforced then EKEYREJECTED is returned. (b) If IMA will have validated the

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

Jiri Bohac wrote: > Key verification may and will fail for lots of reasons which is > just going to make a user's life harder. E.g. you want to kexec > an old kernel with an expired key. Or your date is just wrong and > you get -EKEYEXPIRED. Note that we can't check for expired

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

Jiri Bohac wrote: > > If sig_err is -EKEYREJECTED, -EKEYEXPIRED or -EKEYREVOKED then it must fail, > > even if the signature check isn't forced. > > It wasn't my intention to fail in these cases. What additional > security does this bring? If simply stripping an invalid >

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

Jiri Bohac wrote: > > Having said that, I do see your point, I think. We should still let through > > validly signed images, even if signatures aren't mandatory in lockdown mode. > > yes, to be clear, the problem I'm trying to fix is: > - without CONFIG_KEXEC_VERIFY_SIG kexec

Re: [PATCH 08a/30] kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE

I think that your code isn't quite right. Looking at the patched code: #ifdef CONFIG_KEXEC_SIG sig_err = arch_kexec_kernel_verify_sig(image, image->kernel_buf, image->kernel_buf_len); if (sig_err) pr_debug("kernel

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

David Howells <dhowe...@redhat.com> wrote: > > I don't like the idea that the lockdown (which is a runtime > > thing) requires a compile time option (KEXEC_VERIFY_SIG) that > > forces the verification even when the kernel is then not locked > > down at runtime. &g

Re: [PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

Jiri Bohac wrote: > I don't like the idea that the lockdown (which is a runtime > thing) requires a compile time option (KEXEC_VERIFY_SIG) that > forces the verification even when the kernel is then not locked > down at runtime. It doesn't. The EPERM only triggers if: (1)

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

Alan Cox wrote: > So you don't actually need to sign a lot of PC class firmware because > it's already signed. Whilst that may be true, we either have to check signatures on every bit of firmware that the appropriate driver doesn't say is meant to be signed or not

Re: [PATCH 26/30] Lock down ftrace

Okay, I've dropped the ftrace lockdown patch for the moment from my git branch. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 26/30] Lock down ftrace

Jiri Kosina wrote: > > The idea is to prevent cryptographic data for filesystems and other things > > from being read out of the kernel memory as well as to prevent unauthorised > > modification of kernel memory. > > Then it would make sense to actually lock down dumping of

Re: [PATCH 26/30] Lock down ftrace

Jiri Kosina wrote: > > This prevents crypto data theft by analysis of execution patterns, and, if > > in future ftrace also logs the register contents at the time, will prevent > > data theft by that mechanism also. > > I fail to see how this fits into the secure boot security

[PATCH 00/30] security, efi: Add kernel lockdown

own David --- Chun-Yi Lee (1): kexec_file: Restrict at runtime if the kernel is locked down Dave Young (1): Copy secure_boot flag in boot params across kexec reboot David Howells (14): Add the ability to lock down access to the running kernel image Enforce module

[PATCH 01/30] Add the ability to lock down access to the running kernel image

registers and disallowing hibernation, Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: James Morris <james.l.mor...@oracle.com> --- include/linux/kernel.h | 17 + include/linux/security.h |8 ++ security/Kconfig |8 ++ secur

[PATCH 03/30] ima: require secure_boot rules in lockdown mode

From: Mimi Zohar <zo...@linux.vnet.ibm.com> Require the "secure_boot" rules, whether or not it is specified on the boot command line, for both the builtin and custom policies in secure boot lockdown mode. Signed-off-by: Mimi Zohar <zo...@linux.vnet.ibm.com> Signed-off-by

[PATCH 06/30] kexec: Disable at runtime if the kernel is locked down

nature on the image to be booted. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Dave Young <dyo...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> Reviewed-by: James M

[PATCH 07/30] Copy secure_boot flag in boot params across kexec reboot

to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young <dyo...@redhat.com> Signed-off-by: David Ho

[PATCH 05/30] Restrict /dev/{mem, kmem, port} when the kernel is locked down

opened this when the kernel has been locked down to prevent this. Also disallow /dev/port from being opened to prevent raw ioport access and thus DMA from being used to accomplish the same thing. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhow

[PATCH 11/30] PCI: Lock down BAR access when the kernel is locked down

future we can potentially relax this for sufficiently IOMMU-isolated devices. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> Reviewed-by: "Lee, Chun-

[PATCH 08/30] kexec_file: Restrict at runtime if the kernel is locked down

g/lkml/2015/3/13/778 Cc: Matthew Garrett <mj...@srcf.ucam.org> Signed-off-by: Chun-Yi Lee <j...@suse.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> cc: ke...@lists.infradead.org --- kernel/kexec_file.c |

[PATCH 10/30] uswsusp: Disable when the kernel is locked down

From: Matthew Garrett <mj...@srcf.ucam.org> uswsusp allows a user process to dump and then restore kernel state, which makes it possible to modify the running kernel. Disable this if the kernel is locked down. Signed-off-by: Matthew Garrett <mj...@srcf.ucam.org> Signed-off-by: D

[PATCH 12/30] x86: Lock down IO port access when the kernel is locked down

efault. This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de> Reviewed-by: "Lee

[PATCH 14/30] asus-wmi: Restrict debugfs interface when the kernel is locked down

module loading restrictions. Prevent that if the kernel is locked down. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> cc: acpi4asus-u...@lists.s

[PATCH 13/30] x86/msr: Restrict MSR access when the kernel is locked down

as per Alan Cox's suggestion. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Kees Cook <keesc...@chromium.org> Reviewed-by: Thomas Gleixner <t...@linutronix.de> Reviewed-by: "Lee, Chun-Yi" <j.

[PATCH 15/30] ACPI: Limit access to custom_method when the kernel is locked down

thew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> cc: linux-a...@vger.kernel.org --- drivers/acpi/custom_method.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/custom_method.c b/

[PATCH 17/30] acpi: Disable ACPI table override if the kernel is locked down

el is set, the kernel should disallow any unauthenticated changes to kernel space. ACPI tables contain code invoked by the kernel, so do not allow ACPI tables to be overridden if the kernel is locked down. Signed-off-by: Linn Crosetto <l...@hpe.com> Signed-off-by: David Howells <dhowe...@re

[PATCH 19/30] scsi: Lock down the eata driver

ed-off-by: David Howells <dhowe...@redhat.com> cc: Dario Ballabio <ballabio_da...@emc.com> cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com> cc: "Martin K. Petersen" <martin.peter...@oracle.com> cc: linux-s...@vger.kernel.org --- drivers/scsi/eata.c |5

[PATCH 16/30] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

; Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> cc: Dave Young <dyo...@redhat.com> cc: linux-a...@vger.kernel.org --- drivers/acpi/osl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c

[PATCH 18/30] acpi: Disable APEI error injection if the kernel is locked down

method to load unauthenticated privileged code, the effect of these errors may persist across reboots and affect trust in the underlying hardware, so disable error injection through EINJ if the kernel is locked down. Signed-off-by: Linn Crosetto <l...@hpe.com> Signed-off-by: David Howells <dhow

[PATCH 20/30] Prohibit PCMCIA CIS storage when the kernel is locked down

Prohibit replacement of the PCMCIA Card Information Structure when the kernel is locked down. Suggested-by: Dominik Brodowski <li...@dominikbrodowski.net> Signed-off-by: David Howells <dhowe...@redhat.com> cc: linux-pcm...@lists.infradead.org --- drivers/pcmcia/cistpl.c |3

[PATCH 21/30] Lock down TIOCSSERIAL

-Hartman <gre...@linuxfoundation.org> Signed-off-by: David Howells <dhowe...@redhat.com> cc: Jiri Slaby <jsl...@suse.com> --- drivers/tty/serial/serial_core.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/s

[PATCH 23/30] x86/mmiotrace: Lock down the testmmiotrace module

The testmmiotrace module shouldn't be permitted when the kernel is locked down as it can be used to arbitrarily read and write MMIO space. Suggested-by: Thomas Gleixner <t...@linutronix.de> Signed-off-by: David Howells <dhowe...@redhat.com cc: Thomas Gleixner <t...@linutronix.de

[PATCH 24/30] debugfs: Disallow use of debugfs files when the kernel is locked down

be done through configfs or a miscdev, not debugfs. Note that this makes it unnecessary to specifically lock down show_dsts(), show_devs() and show_call() in the asus-wmi driver. Signed-off-by: David Howells <dhowe...@redhat.com> cc: Andy Shevchenko <andy.shevche...@gmail.com> cc:

[PATCH 22/30] Lock down module params that specify hardware parameters (eg. ioport)

Provided an annotation for module parameters that specify hardware parameters (such as io ports, iomem addresses, irqs, dma channels, fixed dma buffers and other types). Suggested-by: Alan Cox <gno...@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowe...@redhat.com> --- ker

[PATCH 25/30] Lock down /proc/kcore

Disallow access to /proc/kcore when the kernel is locked down to prevent access to cryptographic data. Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> --- fs/proc/kcore.c |2 ++ 1 file changed, 2 insertions(+) diff --g

[PATCH 26/30] Lock down ftrace

, will prevent data theft by that mechanism also. Reported-by: Alexei Starovoitov <alexei.starovoi...@gmail.com> Signed-off-by: David Howells <dhowe...@redhat.com> --- kernel/trace/ftrace.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/kernel/trace/ftrac

[PATCH 28/30] bpf: Restrict kernel image access functions when the kernel is locked down

. Completely prohibit the use of BPF when the kernel is locked down. Suggested-by: Alexei Starovoitov <alexei.starovoi...@gmail.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: net...@vger.kernel.org cc: Chun-Yi Lee <j...@suse.com> cc: Alexei Starovoitov <alexei.

[PATCH 27/30] Lock down kprobes

ed-off-by: David Howells <dhowe...@redhat.com> --- kernel/kprobes.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index a1606a4224e1..f06023b0936c 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1530,6 +1530,9 @@ int register_kprobe(stru

[PATCH 29/30] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

there. Suggested-by: Ard Biesheuvel <ard.biesheu...@linaro.org> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org> cc: linux-efi@vger.kernel.org --- arch/x86/kernel/setup.c | 14 +- drivers/firmware/efi/M

[PATCH 30/30] efi: Lock down the kernel if booted in secure boot mode

- if the kernel is secure-booted. Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> cc: linux-efi@vger.kernel.org --- arch/x86/kernel/setup.c |6 -- security/Kconfig| 14 ++ security/lock_down.c

[PATCH 09/30] hibernate: Disable when the kernel is locked down

ed-off-by: Josh Boyer <jwbo...@fedoraproject.org> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> cc: linux...@vger.kernel.org --- kernel/power/hibernate.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[PATCH 04/30] Enforce module signatures if the kernel is locked down

If the kernel is locked down, require that all modules have valid signatures that we can verify or that IMA can validate the file. Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> Reviewed-by: James Morris <james.l.mor...

[PATCH 02/30] Add a SysRq option to lift kernel lockdown

etting LOCKDOWN_LIFT_KEY in asm/setup.h. Since this macro must be defined in an arch to be able to use this facility for that arch, the Kconfig option is restricted to arches that support it. Signed-off-by: Kyle McMartin <k...@redhat.com> Signed-off-by: David Howells <dhowe...@re

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Alexei Starovoitov wrote: > > TBH, I've no idea how bpf does anything, so I can't say whether this is > > better, overkill or insufficient. > > ok. To make it clear: > Nacked-by: Alexei Starovoitov > For the current patch. > Unnecessary checks for

Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown

Thiago Jung Bauermann wrote: > On non-x86 platforms (tested on powerpc) this fails to build with: > > security/lock_down.c: In function ‘lockdown_lift_sysrq’: > security/lock_down.c:100:40: error: ‘LOCKDOWN_LIFT_KEY’ undeclared (first use > in this function) >

Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

Mimi Zohar wrote: > > Only validly signed device firmware may be loaded. > > fw_get_filesystem_firmware() calls kernel_read_file_from_path() to > read the firmware, which calls into the security hooks. Is there > another place that validates the firmware signatures.  

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Mimi Zohar wrote: > Right, it would never get here if the IMA signature verification > fails.  If sig_enforce is not enabled, then it will also work.  So the > only case is if sig_enforced is enabled and there is no key. > > eg. >          else if (can_do_ima_check &&

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Mimi Zohar wrote: > By this point, IMA-appraisal has already verified the kernel module > signature back in kernel_read_file_from_fd(), if it was required. >  Having a key with which to verify the appended signature or requiring > an appended signature, should not be

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

.ucam.org> Signed-off-by: Chun-Yi Lee <j...@suse.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: James Morris <james.l.mor...@oracle.com> cc: ke...@lists.infradead.org diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 9f4

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Hi Mimi, I've altered this patch to allow for IMA appraisal on finit_module(). See the attached. David --- commit c0d5336356004e7543314e388755a00e725521da Author: David Howells <dhowe...@redhat.com> Date: Wed May 24 14:56:01 2017 +0100 Enforce module signatures if the kernel is

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar wrote: > At some point, we'll want to also require the initramfs be signed as well. That could be tricky. In Fedora, at least, that's assembled on the fly to include just the drivers you need to be able to mount your root fs and find the rest of your

Re: [PATCH 03/27] Enforce module signatures if the kernel is locked down

Mimi Zohar wrote: > This kernel_is_locked_down() check is being called for both the > original and new module_load syscalls.  We need to be able > differentiate them.  This is fine for the original syscall, but for > the new syscall we would need an additional IMA check

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar wrote: > Huh?!  With the "secure_boot" policy enabled on the boot command line, > IMA-appraisal would verify the kexec kernel image, firmware, kernel > modules, and custom IMA policy signatures. What happens if the "secure_boot" policy isn't enabled on the

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar wrote: > Yes, that works.  Thanks!  Remember is_ima_appraise_enabled() is > dependent on the "ima: require secure_boot rules in lockdown mode" > patch - http://kernsec.org/pipermail/linux-security-module-archive/201 > 7-October/003910.html. What happens if

[GIT PULL] Kernel lockdown for secure boot

. and there are some changes recently proposed that make it work with IMA that I'll pass on as a follow up when we've fully worked them out. There's a manual page (kernel_lockdown.7) associated with this: .\" .\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved. .\" Written by David

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

joeyli wrote: > + if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && > + !is_ima_appraise_enabled() && > + kernel_is_locked_down("kexec of unsigned images")) This doesn't seem right. It seems that you can then kexec unsigned images into a locked-down kernel if IMA

Re: [PATCH 07/27] kexec_file: Disable at runtime if securelevel has been set

Mimi Zohar wrote: > The patch title and description needs to be updated to refer to > lockdown, not securelevel. Fixed, thanks. > An additional patch could force these rules to be added to the custom > policy, if lockdown is enabled. I'll have a look at your patch,

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

Ethan Zhao wrote: > May I ask a question here -- Is it intentionally enabling the > read-only mode, so userspace > tools like dmidecode could work with kernel_is_locked_down ? while it > was impossible to work > with the attached patch applied. Is it a security

Re: [PATCH 26/27] efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

James Morris wrote: > > + default: > > + pr_info("Secure boot could not be determined\n"); > > Perhaps make this pr_warning and include the unknown mode value? Done. David -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

j...@suse.com wrote: > hm... patch 4 only prevents write_mem() but not read_mem(). > Or I missed anything? Actually, yes, as it happens, patch 11 prevents you from even opening /dev/mem and /dev/kmem by locking down open of /dev/port. So I've moved this bit to patch 4, simplified and posted a

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

Alan Cox wrote: > There are a load of standard tools that use this so I think you are going > to need a whitelist. Can you at least log *which* MSR in the failing case > so a whitelist can be built over time ? Will the attached change work for you? David --- diff

Re: [PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

atthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: "Lee, Chun-Yi" <j...@suse.com> diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 593a8818aca9..0ce5ac0a5c6b 100644 --- a/drivers/char/mem.c +++ b/d

Re: [PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

Alan Cox wrote: > There are a load of standard tools that use this so I think you are going > to need a whitelist. Can you at least log *which* MSR in the failing case > so a whitelist can be built over time ? Probably. Is it just the file position for msr_write()?

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

j...@suse.com wrote: > I think that we don't need to lock down sys_bpf() now because > we didn't lock down other interfaces for reading arbitrary > address like /dev/mem and /dev/kmem. Ummm... See patch 4. You even gave me a Reviewed-by for it ;-) David -- To unsubscribe from this list: send

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Hi Joey, Should I just lock down sys_bpf() entirely for now? We can always free it up somewhat later. David -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 18/27] bpf: Restrict kernel image access functions when the kernel is locked down

Alexei Starovoitov wrote: > > @@ -65,6 +65,11 @@ BPF_CALL_3(bpf_probe_read, void *, dst, u32, size, const > > void *, unsafe_ptr) > > { > > int ret; > > > > + if (kernel_is_locked_down("BPF")) { > > + memset(dst, 0, size); > > + return

Re: [PATCH 02/27] Add a SysRq option to lift kernel lockdown

Randy Dunlap wrote: > > +config ALLOW_LOCKDOWN_LIFT > > + bool > > + help > > + Allow the lockdown on a kernel to be lifted, thereby restoring the > > + ability of userspace to access the kernel image (eg. by SysRq+x under > > how about:

[PATCH 01/27] Add the ability to lock down access to the running kernel image

registers and disallowing hibernation, Signed-off-by: David Howells <dhowe...@redhat.com> --- include/linux/kernel.h | 17 + include/linux/security.h |8 ++ security/Kconfig |8 ++ security/Makefile|3 ++ security/lock_down.c

[PATCH 02/27] Add a SysRq option to lift kernel lockdown

is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h. Signed-off-by: Kyle McMartin <k...@redhat.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: x...@kernel.org --- arch/x86/include/asm/setup.h |2 ++ drivers/input/misc/uinput.c |1 + drivers/tty/sysrq

[PATCH 03/27] Enforce module signatures if the kernel is locked down

If the kernel is locked down, require that all modules have valid signatures that we can verify. Signed-off-by: David Howells <dhowe...@redhat.com> --- kernel/module.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/module.c b/kernel/module.c index de66ec

[PATCH 04/27] Restrict /dev/mem and /dev/kmem when the kernel is locked down

ebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> --- drivers/char/mem.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/char/mem.c b/drivers/char/mem.c index 593a8818aca9..b7c36898b689 100644 --- a/drivers/char/mem.c +++ b/drivers/char/mem.c @@ -179,6 +179,9

[PATCH 05/27] kexec: Disable at runtime if the kernel is locked down

nature on the image to be booted. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Dave Young <dyo...@redhat.com> cc: ke...@lists.infradead.org --- kernel/kexec.c |7 +++ 1 file changed, 7 insertions

[PATCH 06/27] Copy secure_boot flag in boot params across kexec reboot

to fix this by retain the secure_boot flag in original kernel. secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the stub. Fixing this issue by copying secure_boot flag across kexec reboot. Signed-off-by: Dave Young <dyo...@redhat.com> Signed-off-by: David Ho

[PATCH 09/27] uswsusp: Disable when the kernel is locked down

From: Matthew Garrett <mj...@srcf.ucam.org> uswsusp allows a user process to dump and then restore kernel state, which makes it possible to modify the running kernel. Disable this if the kernel is locked down. Signed-off-by: Matthew Garrett <mj...@srcf.ucam.org> Signed-off-by: D

[PATCH 12/27] x86/msr: Restrict MSR access when the kernel is locked down

; Signed-off-by: David Howells <dhowe...@redhat.com> Acked-by: Kees Cook <keesc...@chromium.org> Reviewed-by: Thomas Gleixner <t...@linutronix.de> cc: x...@kernel.org --- arch/x86/kernel/msr.c |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/kernel/msr.c

[PATCH 08/27] hibernate: Disable when the kernel is locked down

ed-off-by: Josh Boyer <jwbo...@fedoraproject.org> Signed-off-by: David Howells <dhowe...@redhat.com> cc: linux...@vger.kernel.org --- kernel/power/hibernate.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c

[PATCH 11/27] x86: Lock down IO port access when the kernel is locked down

efault. This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and KDDISABIO console ioctls. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> Reviewed-by: Thomas Gleixner <t...@linutronix.de> cc: x...@kernel.o

[PATCH 13/27] asus-wmi: Restrict debugfs interface when the kernel is locked down

module loading restrictions. Prevent that if the kernel is locked down. Signed-off-by: Matthew Garrett <matthew.garr...@nebula.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: acpi4asus-u...@lists.sourceforge.net cc: platform-driver-...@vger.kernel.org --- drivers/platf

[PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

; Signed-off-by: David Howells <dhowe...@redhat.com> cc: Dave Young <dyo...@redhat.com> cc: linux-a...@vger.kernel.org --- drivers/acpi/osl.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index db78d353bab1..36c6527c1b0a 100644

[PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down

el is set, the kernel should disallow any unauthenticated changes to kernel space. ACPI tables contain code invoked by the kernel, so do not allow ACPI tables to be overridden if the kernel is locked down. Signed-off-by: Linn Crosetto <l...@hpe.com> Signed-off-by: David Howells <dhowe...@red

  1   2   3   >