Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1617335 > unrolled thread

[PATCH 00/24] Kernel lockdown

Started byDavid Howells <dhowells@redhat.com>
First post2017-04-05 22:20 +0200
Last post2017-04-07 18:40 +0200
Articles 20 on this page of 47 — 12 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 00/24] Kernel lockdown David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 24/24] Lock down module params that specify hardware  parameters (eg. ioport) David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 03/24] efi: Lock down the kernel if booted in secure boot  mode David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 20/24] bpf: Restrict kernel image access functions when the  kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 20/24] bpf: Restrict kernel image access functions when  the kernel is locked down Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2017-04-06 14:30 +0200
        Re: [PATCH 20/24] bpf: Restrict kernel image access functions when  the kernel is locked down Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-04-06 14:50 +0200
    [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked  down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel  is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the  kernel is locked down Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-07 12:30 +0200
        Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-07 15:00 +0200
          Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the  kernel is locked down Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-09 13:20 +0200
            Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-10 15:20 +0200
    [PATCH 02/24] Add the ability to lock down access to the running  kernel image David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
      Re: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked  down Dave Young <dyoung@redhat.com> - 2017-04-07 05:10 +0200
    [PATCH 08/24] Copy secure_boot flag in boot params across kexec  reboot David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 06/24] Add a sysrq option to exit secure boot mode David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 10/24] hibernate: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:20 +0200
    [PATCH 14/24] x86: Restrict MSR access when the kernel is locked  down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
    [PATCH 04/24] Enforce module signatures if the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
    [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
      Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 01:40 +0200
        Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down Oliver Neukum <oneukum@suse.com> - 2017-04-06 08:50 +0200
          Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-06 11:30 +0200
            Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
              Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down Jiri Kosina <jikos@kernel.org> - 2017-04-06 22:30 +0200
                Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down poma <pomidorabelisima@gmail.com> - 2017-04-08 05:30 +0200
            Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
        Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-06 09:00 +0200
          Re: [PATCH 11/24] uswsusp: Disable when the kernel is locked down "Rafael J. Wysocki" <rafael@kernel.org> - 2017-04-06 22:20 +0200
    [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set David Howells <dhowells@redhat.com> - 2017-04-05 22:30 +0200
      Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 05:10 +0200
        Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 05:50 +0200
          Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 08:20 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 09:10 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 09:50 +0200
                Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 10:30 +0200
                  Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 10:50 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 09:50 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Dave Young <dyoung@redhat.com> - 2017-04-07 10:10 +0200
          Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 09:20 +0200
            Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 09:50 +0200
              Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-07 11:20 +0200
                Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has  been set Mimi Zohar <zohar@linux.vnet.ibm.com> - 2017-04-07 14:40 +0200
                  Re: [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set David Howells <dhowells@redhat.com> - 2017-04-10 15:30 +0200
    Re: [PATCH 00/24] Kernel lockdown "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2017-04-07 18:10 +0200
      Re: [PATCH 00/24] Kernel lockdown Justin Forbes <jmforbes@linuxtx.org> - 2017-04-07 18:40 +0200

Page 1 of 3  [1] 2 3  Next page →


#1617335 — [PATCH 00/24] Kernel lockdown

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 00/24] Kernel lockdown
Message-ID<tsZzj-7hF-5@gated-at.bofh.it>
These patches provide a facility by which a variety of avenues by which
userspace can feasibly modify the running kernel image can be locked down.
These include:

 (*) No unsigned modules and no modules for which can't validate the
     signature.

 (*) No use of ioperm(), iopl() and no writing to /dev/port.

 (*) No writing to /dev/mem or /dev/kmem.

 (*) No hibernation.

 (*) Restrict PCI BAR access.

 (*) Restrict MSR access.

 (*) No kexec_load().

 (*) Certain ACPI restrictions.

 (*) Restrict debugfs interface to ASUS WMI.

The lock-down can be configured to be triggered by the EFI secure boot
status, provided the shim isn't insecure.  The lock-down can be lifted by
typing SysRq+x on a keyboard attached to the system.


The patches can be found here also:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lockdown

They are dependent on the hwparam branch, which I posted separately.

David
---
Chun-Yi Lee (2):
      kexec_file: Disable at runtime if securelevel has been set
      bpf: Restrict kernel image access functions when the kernel is locked down

Dave Young (1):
      Copy secure_boot flag in boot params across kexec reboot

David Howells (7):
      Add the ability to lock down access to the running kernel image
      efi: Lock down the kernel if booted in secure boot mode
      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)

Josh Boyer (3):
      efi: Add EFI_SECURE_BOOT bit
      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 exit secure boot mode

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 (8):
      Restrict /dev/mem and /dev/kmem when the kernel is locked down
      kexec: 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: Restrict MSR access when the kernel is locked down
      asus-wmi: Restrict debugfs interface when the kernel is locked down
      ACPI: Limit access to custom_method when the kernel is locked down


 arch/x86/Kconfig                  |   22 ++++++++++++++++++++
 arch/x86/kernel/ioport.c          |    4 ++--
 arch/x86/kernel/kexec-bzimage64.c |    1 +
 arch/x86/kernel/msr.c             |    7 ++++++
 arch/x86/kernel/setup.c           |   40 ++++++++++++++++++++++++++++++++++++-
 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                |    8 +++++++
 drivers/input/misc/uinput.c       |    1 +
 drivers/pci/pci-sysfs.c           |    9 ++++++++
 drivers/pci/proc.c                |    8 ++++++-
 drivers/pci/syscall.c             |    2 +-
 drivers/pcmcia/cistpl.c           |    5 +++++
 drivers/platform/x86/asus-wmi.c   |    9 ++++++++
 drivers/scsi/eata.c               |    7 ++++++
 drivers/tty/serial/serial_core.c  |    6 ++++++
 drivers/tty/sysrq.c               |   19 ++++++++++++------
 include/linux/efi.h               |    1 +
 include/linux/input.h             |    5 +++++
 include/linux/kernel.h            |    9 ++++++++
 include/linux/security.h          |   11 ++++++++++
 include/linux/sysrq.h             |    8 ++++++-
 kernel/debug/kdb/kdb_main.c       |    2 +-
 kernel/kexec.c                    |    7 ++++++
 kernel/kexec_file.c               |    6 ++++++
 kernel/module.c                   |    2 +-
 kernel/params.c                   |   27 ++++++++++++++++++++-----
 kernel/power/hibernate.c          |    2 +-
 kernel/power/user.c               |    3 +++
 kernel/trace/bpf_trace.c          |   11 ++++++++++
 security/Kconfig                  |   15 ++++++++++++++
 security/Makefile                 |    3 +++
 security/lock_down.c              |   40 +++++++++++++++++++++++++++++++++++++
 35 files changed, 291 insertions(+), 22 deletions(-)
 create mode 100644 security/lock_down.c

[toc] | [next] | [standalone]


#1617336 — [PATCH 24/24] Lock down module params that specify hardware parameters (eg. ioport)

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 24/24] Lock down module params that specify hardware parameters (eg. ioport)
Message-ID<tsZzl-7hF-41@gated-at.bofh.it>
In reply to#1617335
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 <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
---

 kernel/params.c |   27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/kernel/params.c b/kernel/params.c
index a6d6149c0fe6..04185c5aa929 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -108,13 +108,20 @@ bool parameq(const char *a, const char *b)
 	return parameqn(a, b, strlen(a)+1);
 }
 
-static void param_check_unsafe(const struct kernel_param *kp)
+static bool param_check_unsafe(const struct kernel_param *kp,
+			       const char *doing)
 {
 	if (kp->flags & KERNEL_PARAM_FL_UNSAFE) {
 		pr_warn("Setting dangerous option %s - tainting kernel\n",
 			kp->name);
 		add_taint(TAINT_USER, LOCKDEP_STILL_OK);
 	}
+
+	if (kp->flags & KERNEL_PARAM_FL_HWPARAM && kernel_is_locked_down()) {
+		pr_err("Command line-specified device addresses, irqs and dma channels are not permitted when the kernel is locked down (%s.%s)\n", doing, kp->name);
+		return false;
+	}
+	return true;
 }
 
 static int parse_one(char *param,
@@ -144,8 +151,10 @@ static int parse_one(char *param,
 			pr_debug("handling %s with %p\n", param,
 				params[i].ops->set);
 			kernel_param_lock(params[i].mod);
-			param_check_unsafe(&params[i]);
-			err = params[i].ops->set(val, &params[i]);
+			if (param_check_unsafe(&params[i], doing))
+				err = params[i].ops->set(val, &params[i]);
+			else
+				err = -EPERM;
 			kernel_param_unlock(params[i].mod);
 			return err;
 		}
@@ -608,6 +617,12 @@ static ssize_t param_attr_show(struct module_attribute *mattr,
 	return count;
 }
 
+#ifdef CONFIG_MODULES
+#define mod_name(mod) (mod)->name
+#else
+#define mod_name(mod) "unknown"
+#endif
+
 /* sysfs always hands a nul-terminated string in buf.  We rely on that. */
 static ssize_t param_attr_store(struct module_attribute *mattr,
 				struct module_kobject *mk,
@@ -620,8 +635,10 @@ static ssize_t param_attr_store(struct module_attribute *mattr,
 		return -EPERM;
 
 	kernel_param_lock(mk->mod);
-	param_check_unsafe(attribute->param);
-	err = attribute->param->ops->set(buf, attribute->param);
+	if (param_check_unsafe(attribute->param, mod_name(mk->mod)))
+		err = attribute->param->ops->set(buf, attribute->param);
+	else
+		err = -EPERM;
 	kernel_param_unlock(mk->mod);
 	if (!err)
 		return len;

[toc] | [prev] | [next] | [standalone]


#1617337 — [PATCH 03/24] efi: Lock down the kernel if booted in secure boot mode

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 03/24] efi: Lock down the kernel if booted in secure boot mode
Message-ID<tsZzk-7hF-31@gated-at.bofh.it>
In reply to#1617335
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels.  Certain use cases may also
require that all kernel modules also be signed.  Add a configuration option
that to lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-efi@vger.kernel.org
---

 arch/x86/Kconfig        |   12 ++++++++++++
 arch/x86/kernel/setup.c |    8 +++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a294ee..21f39855661d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1817,6 +1817,18 @@ config EFI_MIXED
 
 	   If unsure, say N.
 
+config EFI_SECURE_BOOT_LOCK_DOWN
+	def_bool n
+	depends on EFI
+	prompt "Lock down the kernel when UEFI Secure Boot is enabled"
+	---help---
+	  UEFI Secure Boot provides a mechanism for ensuring that the firmware
+	  will only load signed bootloaders and kernels.  Certain use cases may
+	  also require that all kernel modules also be signed and that
+	  userspace is prevented from directly changing the running kernel
+	  image.  Say Y here to automatically lock down the kernel when a
+	  system boots with UEFI Secure Boot enabled.
+
 config SECCOMP
 	def_bool y
 	prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 396285bddb93..85dfa745c442 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -69,6 +69,7 @@
 #include <linux/crash_dump.h>
 #include <linux/tboot.h>
 #include <linux/jiffies.h>
+#include <linux/security.h>
 
 #include <video/edid.h>
 
@@ -1185,7 +1186,12 @@ void __init setup_arch(char **cmdline_p)
 			break;
 		case efi_secureboot_mode_enabled:
 			set_bit(EFI_SECURE_BOOT, &efi.flags);
-			pr_info("Secure boot enabled\n");
+			if (IS_ENABLED(CONFIG_EFI_SECURE_BOOT_LOCK_DOWN)) {
+				lock_kernel_down();
+				pr_info("Secure boot enabled and kernel locked down\n");
+			} else {
+				pr_info("Secure boot enabled\n");
+			}
 			break;
 		default:
 			pr_info("Secure boot could not be determined\n");

[toc] | [prev] | [next] | [standalone]


#1617338 — [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down
Message-ID<tsZzl-7hF-37@gated-at.bofh.it>
In reply to#1617335
From: Chun-Yi Lee <jlee@suse.com>

There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program.  Prohibit those functions when the kernel is
locked down.

Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
---

 kernel/trace/bpf_trace.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index cee9802cf3e0..7fde851f207b 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -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()) {
+		memset(dst, 0, size);
+		return -EPERM;
+	}
+
 	ret = probe_kernel_read(dst, unsafe_ptr, size);
 	if (unlikely(ret < 0))
 		memset(dst, 0, size);
@@ -84,6 +89,9 @@ static const struct bpf_func_proto bpf_probe_read_proto = {
 BPF_CALL_3(bpf_probe_write_user, void *, unsafe_ptr, const void *, src,
 	   u32, size)
 {
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	/*
 	 * Ensure we're in user context which is safe for the helper to
 	 * run. This helper has no business in a kthread.
@@ -143,6 +151,9 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size, u64, arg1,
 	if (fmt[--fmt_size] != 0)
 		return -EINVAL;
 
+	if (kernel_is_locked_down())
+		return __trace_printk(1, fmt, 0, 0, 0);
+
 	/* check format string for allowed specifiers */
 	for (i = 0; i < fmt_size; i++) {
 		if ((!isprint(fmt[i]) && !isspace(fmt[i])) || !isascii(fmt[i]))

[toc] | [prev] | [next] | [standalone]


#1617937 — Re: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down

FromAlexei Starovoitov <alexei.starovoitov@gmail.com>
Date2017-04-06 14:30 +0200
SubjectRe: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down
Message-ID<tteI3-8tl-45@gated-at.bofh.it>
In reply to#1617338
On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote:
> From: Chun-Yi Lee <jlee@suse.com>
> 
> There are some bpf functions can be used to read kernel memory:
> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
> private keys in kernel memory (e.g. the hibernation image signing key) to
> be read by an eBPF program.  Prohibit those functions when the kernel is
> locked down.
> 
> Signed-off-by: Chun-Yi Lee <jlee@suse.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: netdev@vger.kernel.org
> ---
> 
>  kernel/trace/bpf_trace.c |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index cee9802cf3e0..7fde851f207b 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -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()) {
> +		memset(dst, 0, size);
> +		return -EPERM;
> +	}

this will obviously break the program. How about disabling loading tracing
programs during the lockdown completely?

Also is there a description of what this lockdown trying to accomplish?
The cover letter is scarce in details.

[toc] | [prev] | [next] | [standalone]


#1617965 — Re: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down

FromArd Biesheuvel <ard.biesheuvel@linaro.org>
Date2017-04-06 14:50 +0200
SubjectRe: [PATCH 20/24] bpf: Restrict kernel image access functions when the kernel is locked down
Message-ID<ttf1n-8X-1@gated-at.bofh.it>
In reply to#1617937
On 6 April 2017 at 13:29, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Wed, Apr 05, 2017 at 09:17:25PM +0100, David Howells wrote:
>> From: Chun-Yi Lee <jlee@suse.com>
>>
>> There are some bpf functions can be used to read kernel memory:
>> bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
>> private keys in kernel memory (e.g. the hibernation image signing key) to
>> be read by an eBPF program.  Prohibit those functions when the kernel is
>> locked down.
>>
>> Signed-off-by: Chun-Yi Lee <jlee@suse.com>
>> Signed-off-by: David Howells <dhowells@redhat.com>
>> cc: netdev@vger.kernel.org
>> ---
>>
>>  kernel/trace/bpf_trace.c |   11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
>> index cee9802cf3e0..7fde851f207b 100644
>> --- a/kernel/trace/bpf_trace.c
>> +++ b/kernel/trace/bpf_trace.c
>> @@ -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()) {
>> +             memset(dst, 0, size);
>> +             return -EPERM;
>> +     }
>
> this will obviously break the program. How about disabling loading tracing
> programs during the lockdown completely?
>
> Also is there a description of what this lockdown trying to accomplish?
> The cover letter is scarce in details.
>

This is a very good point, and this is actually feedback that was
given (by Alan Cox, iirc) the last time this series was circulated.

This series is a mixed bag of patches that all look like they improve
'security' in one way or the other. But what is lacking is a coherent
view on the threat model, and to what extent all these patches reduce
the vulnerability to such threats. Without that, these patches do very
little beyond giving a false sense of security, imo.

[toc] | [prev] | [next] | [standalone]


#1617340 — [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 12/24] PCI: Lock down BAR access when the kernel is locked down
Message-ID<tsZzk-7hF-27@gated-at.bofh.it>
In reply to#1617335
From: Matthew Garrett <matthew.garrett@nebula.com>

Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pci@vger.kernel.org
---

 drivers/pci/pci-sysfs.c |    9 +++++++++
 drivers/pci/proc.c      |    8 +++++++-
 drivers/pci/syscall.c   |    2 +-
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 25d010d449a3..f70b3668036f 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -727,6 +727,9 @@ static ssize_t pci_write_config(struct file *filp, struct kobject *kobj,
 	loff_t init_off = off;
 	u8 *data = (u8 *) buf;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	if (off > dev->cfg_size)
 		return 0;
 	if (off + count > dev->cfg_size) {
@@ -1018,6 +1021,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
 	resource_size_t start, end;
 	int i;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	for (i = 0; i < PCI_ROM_RESOURCE; i++)
 		if (res == &pdev->resource[i])
 			break;
@@ -1117,6 +1123,9 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
 				     struct bin_attribute *attr, char *buf,
 				     loff_t off, size_t count)
 {
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	return pci_resource_io(filp, kobj, attr, buf, off, count, true);
 }
 
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index f82710a8694d..139d6f09ae7b 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -116,6 +116,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,
 	int size = dev->cfg_size;
 	int cnt;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	if (pos >= size)
 		return 0;
 	if (nbytes >= size)
@@ -195,6 +198,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd,
 #endif /* HAVE_PCI_MMAP */
 	int ret = 0;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	switch (cmd) {
 	case PCIIOC_CONTROLLER:
 		ret = pci_domain_nr(dev->bus);
@@ -233,7 +239,7 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma)
 	struct pci_filp_private *fpriv = file->private_data;
 	int i, ret, write_combine;
 
-	if (!capable(CAP_SYS_RAWIO))
+	if (!capable(CAP_SYS_RAWIO) || kernel_is_locked_down())
 		return -EPERM;
 
 	/* Make sure the caller is mapping a real resource for this device */
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index 9bf993e1f71e..c09524738ceb 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned long, dfn,
 	u32 dword;
 	int err = 0;
 
-	if (!capable(CAP_SYS_ADMIN))
+	if (!capable(CAP_SYS_ADMIN) || kernel_is_locked_down())
 		return -EPERM;
 
 	dev = pci_get_bus_and_slot(bus, dfn);

[toc] | [prev] | [next] | [standalone]


#1617341 — [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Message-ID<tsZzl-7hF-39@gated-at.bofh.it>
In reply to#1617335
From: Matthew Garrett <matthew.garrett@nebula.com>

We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions.  Prevent that if the
kernel is locked down.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
---

 drivers/platform/x86/asus-wmi.c |    9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 8fe5890bf539..feef25076813 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1900,6 +1900,9 @@ static int show_dsts(struct seq_file *m, void *data)
 	int err;
 	u32 retval = -1;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
 
 	if (err < 0)
@@ -1916,6 +1919,9 @@ static int show_devs(struct seq_file *m, void *data)
 	int err;
 	u32 retval = -1;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
 				    &retval);
 
@@ -1940,6 +1946,9 @@ static int show_call(struct seq_file *m, void *data)
 	union acpi_object *obj;
 	acpi_status status;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
 				     1, asus->debug.method_id,
 				     &input, &output);

[toc] | [prev] | [next] | [standalone]


#1618658 — Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-04-07 12:30 +0200
SubjectRe: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Message-ID<ttzjr-5Oz-3@gated-at.bofh.it>
In reply to#1617341
On Wed, Apr 5, 2017 at 11:16 PM, David Howells <dhowells@redhat.com> wrote:
> From: Matthew Garrett <matthew.garrett@nebula.com>
>
> We have no way of validating what all of the Asus WMI methods do on a given
> machine - and there's a risk that some will allow hardware state to be
> manipulated in such a way that arbitrary code can be executed in the
> kernel, circumventing module loading restrictions.  Prevent that if the
> kernel is locked down.

> +       if (kernel_is_locked_down())
> +               return -EPERM;

It looks a bit fragile when responsility of whatever reasons kernel
can't serve become a driver burden.
Can we fix this in debugfs framework instead?

> +
>         err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
>
>         if (err < 0)
> @@ -1916,6 +1919,9 @@ static int show_devs(struct seq_file *m, void *data)
>         int err;
>         u32 retval = -1;
>
> +       if (kernel_is_locked_down())
> +               return -EPERM;
> +
>         err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
>                                     &retval);
>
> @@ -1940,6 +1946,9 @@ static int show_call(struct seq_file *m, void *data)
>         union acpi_object *obj;
>         acpi_status status;
>
> +       if (kernel_is_locked_down())
> +               return -EPERM;
> +
>         status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
>                                      1, asus->debug.method_id,
>                                      &input, &output);
>



-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]


#1618761 — Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-07 15:00 +0200
SubjectRe: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Message-ID<ttBEC-7cJ-17@gated-at.bofh.it>
In reply to#1618658
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> > From: Matthew Garrett <matthew.garrett@nebula.com>
> >
> > We have no way of validating what all of the Asus WMI methods do on a given
> > machine - and there's a risk that some will allow hardware state to be
> > manipulated in such a way that arbitrary code can be executed in the
> > kernel, circumventing module loading restrictions.  Prevent that if the
> > kernel is locked down.
> 
> > +       if (kernel_is_locked_down())
> > +               return -EPERM;
> 
> It looks a bit fragile when responsility of whatever reasons kernel
> can't serve become a driver burden.
> Can we fix this in debugfs framework instead?

Fix it with debugfs how?  We can't offload the decision to userspace.

David

[toc] | [prev] | [next] | [standalone]


#1619482 — Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-04-09 13:20 +0200
SubjectRe: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Message-ID<tuj2V-24s-1@gated-at.bofh.it>
In reply to#1618761
On Fri, Apr 7, 2017 at 3:50 PM, David Howells <dhowells@redhat.com> wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
>> > From: Matthew Garrett <matthew.garrett@nebula.com>
>> >
>> > We have no way of validating what all of the Asus WMI methods do on a given
>> > machine - and there's a risk that some will allow hardware state to be
>> > manipulated in such a way that arbitrary code can be executed in the
>> > kernel, circumventing module loading restrictions.  Prevent that if the
>> > kernel is locked down.
>>
>> > +       if (kernel_is_locked_down())
>> > +               return -EPERM;
>>
>> It looks a bit fragile when responsility of whatever reasons kernel
>> can't serve become a driver burden.
>> Can we fix this in debugfs framework instead?
>
> Fix it with debugfs how?  We can't offload the decision to userspace.

I mean to do at least similar like you have done for module
parameters. So, instead of putting above code to each attribute in
question make a special (marked) attribute instead and debugfs
framework will know how to deal with that.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]


#1619905 — Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-10 15:20 +0200
SubjectRe: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Message-ID<tuHoC-18n-37@gated-at.bofh.it>
In reply to#1619482
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> >> It looks a bit fragile when responsility of whatever reasons kernel
> >> can't serve become a driver burden.
> >> Can we fix this in debugfs framework instead?
> >
> > Fix it with debugfs how?  We can't offload the decision to userspace.
> 
> I mean to do at least similar like you have done for module
> parameters. So, instead of putting above code to each attribute in
> question make a special (marked) attribute instead and debugfs
> framework will know how to deal with that.

Hmmm...  It's tricky in that debugfs doesn't have any of its own structures,
but is entirely built on standard VFS ones, so finding somewhere to store the
information is going to be awkward.  One obvious solution is to entirely lock
down debugfs in secure boot more, but that might be a bit drastic.

Note that it's still going to be a driver burden to some extent anyway.  The
driver has to tell the core what needs to be restricted.

Further, I guess configfs needs attention also.

David

[toc] | [prev] | [next] | [standalone]


#1617342 — [PATCH 02/24] Add the ability to lock down access to the running kernel image

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 02/24] Add the ability to lock down access to the running kernel image
Message-ID<tsZzl-7hF-45@gated-at.bofh.it>
In reply to#1617335
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation,

Signed-off-by: David Howells <dhowells@redhat.com>
---

 include/linux/kernel.h   |    9 +++++++++
 include/linux/security.h |   11 +++++++++++
 security/Kconfig         |   15 +++++++++++++++
 security/Makefile        |    3 +++
 security/lock_down.c     |   40 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 78 insertions(+)
 create mode 100644 security/lock_down.c

diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..b820a80dc949 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -275,6 +275,15 @@ extern int oops_may_print(void);
 void do_exit(long error_code) __noreturn;
 void complete_and_exit(struct completion *, long) __noreturn;
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern bool kernel_is_locked_down(void);
+#else
+static inline bool kernel_is_locked_down(void)
+{
+	return false;
+}
+#endif
+
 /* Internal, do not use. */
 int __must_check _kstrtoul(const char *s, unsigned int base, unsigned long *res);
 int __must_check _kstrtol(const char *s, unsigned int base, long *res);
diff --git a/include/linux/security.h b/include/linux/security.h
index af675b576645..68bab18ddd57 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1698,5 +1698,16 @@ static inline void free_secdata(void *secdata)
 { }
 #endif /* CONFIG_SECURITY */
 
+#ifdef CONFIG_LOCK_DOWN_KERNEL
+extern void lock_kernel_down(void);
+#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT
+extern void lift_kernel_lockdown(void);
+#endif
+#else
+static inline void lock_kernel_down(void)
+{
+}
+#endif
+
 #endif /* ! __LINUX_SECURITY_H */
 
diff --git a/security/Kconfig b/security/Kconfig
index 3ff1bf91080e..e3830171bdcb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -198,6 +198,21 @@ config STATIC_USERMODEHELPER_PATH
 	  If you wish for all usermode helper programs to be disabled,
 	  specify an empty string here (i.e. "").
 
+config LOCK_DOWN_KERNEL
+	bool "Allow the kernel to be 'locked down'"
+	help
+	  Allow the kernel to be locked down under certain circumstances, for
+	  instance if UEFI secure boot is enabled.  Locking down the kernel
+	  turns off various features that might otherwise allow access to the
+	  kernel image (eg. setting MSR registers).
+
+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
+	  x86).
+
 source security/selinux/Kconfig
 source security/smack/Kconfig
 source security/tomoyo/Kconfig
diff --git a/security/Makefile b/security/Makefile
index f2d71cdb8e19..8c4a43e3d4e0 100644
--- a/security/Makefile
+++ b/security/Makefile
@@ -29,3 +29,6 @@ obj-$(CONFIG_CGROUP_DEVICE)		+= device_cgroup.o
 # Object integrity file lists
 subdir-$(CONFIG_INTEGRITY)		+= integrity
 obj-$(CONFIG_INTEGRITY)			+= integrity/
+
+# Allow the kernel to be locked down
+obj-$(CONFIG_LOCK_DOWN_KERNEL)		+= lock_down.o
diff --git a/security/lock_down.c b/security/lock_down.c
new file mode 100644
index 000000000000..5788c60ff4e1
--- /dev/null
+++ b/security/lock_down.c
@@ -0,0 +1,40 @@
+/* Lock down the kernel
+ *
+ * Copyright (C) 2016 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowells@redhat.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+
+#include <linux/security.h>
+#include <linux/export.h>
+
+static __read_mostly bool kernel_locked_down;
+
+/*
+ * Put the kernel into lock-down mode.
+ */
+void lock_kernel_down(void)
+{
+	kernel_locked_down = true;
+}
+
+/*
+ * Take the kernel out of lockdown mode.
+ */
+void lift_kernel_lockdown(void)
+{
+	kernel_locked_down = false;
+}
+
+/**
+ * kernel_is_locked_down - Find out if the kernel is locked down
+ */
+bool kernel_is_locked_down(void)
+{
+	return kernel_locked_down;
+}
+EXPORT_SYMBOL(kernel_is_locked_down);

[toc] | [prev] | [next] | [standalone]


#1617344 — [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 07/24] kexec: Disable at runtime if the kernel is locked down
Message-ID<tsZzl-7hF-51@gated-at.bofh.it>
In reply to#1617335
From: Matthew Garrett <matthew.garrett@nebula.com>

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.

This does not affect kexec_file_load() which can check for a signature on the
image to be booted.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---

 kernel/kexec.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..46de8e6b42f4 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -194,6 +194,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 		return -EPERM;
 
 	/*
+	 * kexec can be used to circumvent module loading restrictions, so
+	 * prevent loading in that case
+	 */
+	if (kernel_is_locked_down())
+		return -EPERM;
+
+	/*
 	 * Verify we have a legal set of flags
 	 * This leaves us room for future extensions.
 	 */

[toc] | [prev] | [next] | [standalone]


#1618458 — Re: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down

FromDave Young <dyoung@redhat.com>
Date2017-04-07 05:10 +0200
SubjectRe: [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down
Message-ID<ttsrD-1tz-3@gated-at.bofh.it>
In reply to#1617344
On 04/05/17 at 09:15pm, David Howells wrote:
> From: Matthew Garrett <matthew.garrett@nebula.com>
> 
> kexec permits the loading and execution of arbitrary code in ring 0, which
> is something that lock-down is meant to prevent. It makes sense to disable
> kexec in this situation.
> 
> This does not affect kexec_file_load() which can check for a signature on the
> image to be booted.
> 
> Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: kexec@lists.infradead.org
> ---
> 
>  kernel/kexec.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 980936a90ee6..46de8e6b42f4 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -194,6 +194,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>  		return -EPERM;
>  
>  	/*
> +	 * kexec can be used to circumvent module loading restrictions, so
> +	 * prevent loading in that case
> +	 */
> +	if (kernel_is_locked_down())
> +		return -EPERM;
> +
> +	/*
>  	 * Verify we have a legal set of flags
>  	 * This leaves us room for future extensions.
>  	 */
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Acked-by: Dave Young <dyoung@redhat.com>

Thanks
Dave

[toc] | [prev] | [next] | [standalone]


#1617345 — [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot
Message-ID<tsZzl-7hF-53@gated-at.bofh.it>
In reply to#1617335
From: Dave Young <dyoung@redhat.com>

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

Adding a patch 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 <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---

 arch/x86/kernel/kexec-bzimage64.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index d0a814a9d96a..3551bcaa1eaf 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
 	if (efi_enabled(EFI_OLD_MEMMAP))
 		return 0;
 
+	params->secure_boot = boot_params.secure_boot;
 	ei->efi_loader_signature = current_ei->efi_loader_signature;
 	ei->efi_systab = current_ei->efi_systab;
 	ei->efi_systab_hi = current_ei->efi_systab_hi;

[toc] | [prev] | [next] | [standalone]


#1617346 — [PATCH 06/24] Add a sysrq option to exit secure boot mode

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 06/24] Add a sysrq option to exit secure boot mode
Message-ID<tsZzl-7hF-47@gated-at.bofh.it>
In reply to#1617335
From: Kyle McMartin <kyle@redhat.com>

Make sysrq+x exit secure boot mode on x86_64, thereby allowing the running
kernel image to be modified.  This lifts the lockdown.

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org
---

 arch/x86/Kconfig            |   10 ++++++++++
 arch/x86/kernel/setup.c     |   31 +++++++++++++++++++++++++++++++
 drivers/input/misc/uinput.c |    1 +
 drivers/tty/sysrq.c         |   19 +++++++++++++------
 include/linux/input.h       |    5 +++++
 include/linux/sysrq.h       |    8 +++++++-
 kernel/debug/kdb/kdb_main.c |    2 +-
 7 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 21f39855661d..457c04971849 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1829,6 +1829,16 @@ config EFI_SECURE_BOOT_LOCK_DOWN
 	  image.  Say Y here to automatically lock down the kernel when a
 	  system boots with UEFI Secure Boot enabled.
 
+config EFI_ALLOW_SECURE_BOOT_EXIT
+	def_bool n
+	depends on EFI_SECURE_BOOT_LOCK_DOWN && MAGIC_SYSRQ
+	select ALLOW_LOCKDOWN_LIFT
+	prompt "Allow secure boot mode to be exited with SysRq+x on a keyboard"
+	---help---
+	  Allow secure boot mode to be exited and the kernel lockdown lifted by
+	  typing SysRq+x on a keyboard attached to the system (not permitted
+	  through procfs).
+
 config SECCOMP
 	def_bool y
 	prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 85dfa745c442..a415a4817684 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -71,6 +71,11 @@
 #include <linux/jiffies.h>
 #include <linux/security.h>
 
+#include <linux/fips.h>
+#include <linux/cred.h>
+#include <linux/sysrq.h>
+#include <linux/init_task.h>
+
 #include <video/edid.h>
 
 #include <asm/mtrr.h>
@@ -1330,6 +1335,32 @@ void __init i386_reserve_resources(void)
 
 #endif /* CONFIG_X86_32 */
 
+#ifdef CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT
+
+static void sysrq_handle_secure_boot(int key)
+{
+	if (!efi_enabled(EFI_SECURE_BOOT))
+		return;
+
+	pr_info("Secure boot disabled\n");
+	lift_kernel_lockdown();
+}
+static struct sysrq_key_op secure_boot_sysrq_op = {
+	.handler	=	sysrq_handle_secure_boot,
+	.help_msg	=	"unSB(x)",
+	.action_msg	=	"Disabling Secure Boot restrictions",
+	.enable_mask	=	SYSRQ_DISABLE_USERSPACE,
+};
+static int __init secure_boot_sysrq(void)
+{
+	if (efi_enabled(EFI_SECURE_BOOT))
+		register_sysrq_key('x', &secure_boot_sysrq_op);
+	return 0;
+}
+late_initcall(secure_boot_sysrq);
+#endif /*CONFIG_EFI_ALLOW_SECURE_BOOT_EXIT*/
+
+
 static struct notifier_block kernel_offset_notifier = {
 	.notifier_call = dump_kernel_offset
 };
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 022be0e22eba..4a054a564636 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -387,6 +387,7 @@ static int uinput_allocate_device(struct uinput_device *udev)
 	if (!udev->dev)
 		return -ENOMEM;
 
+	udev->dev->flags |= INPUTDEV_FLAGS_SYNTHETIC;
 	udev->dev->event = uinput_dev_event;
 	input_set_drvdata(udev->dev, udev);
 
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index c6fc7141d7b2..0c96cf60f1a6 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -481,6 +481,7 @@ static struct sysrq_key_op *sysrq_key_table[36] = {
 	/* x: May be registered on mips for TLB dump */
 	/* x: May be registered on ppc/powerpc for xmon */
 	/* x: May be registered on sparc64 for global PMU dump */
+	/* x: May be registered on x86_64 for disabling secure boot */
 	NULL,				/* x */
 	/* y: May be registered on sparc64 for global register dump */
 	NULL,				/* y */
@@ -524,7 +525,7 @@ static void __sysrq_put_key_op(int key, struct sysrq_key_op *op_p)
                 sysrq_key_table[i] = op_p;
 }
 
-void __handle_sysrq(int key, bool check_mask)
+void __handle_sysrq(int key, unsigned int from)
 {
 	struct sysrq_key_op *op_p;
 	int orig_log_level;
@@ -544,11 +545,15 @@ void __handle_sysrq(int key, bool check_mask)
 
         op_p = __sysrq_get_key_op(key);
         if (op_p) {
+		/* Ban synthetic events from some sysrq functionality */
+		if ((from == SYSRQ_FROM_PROC || from == SYSRQ_FROM_SYNTHETIC) &&
+		    op_p->enable_mask & SYSRQ_DISABLE_USERSPACE)
+			printk("This sysrq operation is disabled from userspace.\n");
 		/*
 		 * Should we check for enabled operations (/proc/sysrq-trigger
 		 * should not) and is the invoked operation enabled?
 		 */
-		if (!check_mask || sysrq_on_mask(op_p->enable_mask)) {
+		if (from == SYSRQ_FROM_KERNEL || sysrq_on_mask(op_p->enable_mask)) {
 			pr_cont("%s\n", op_p->action_msg);
 			console_loglevel = orig_log_level;
 			op_p->handler(key);
@@ -580,7 +585,7 @@ void __handle_sysrq(int key, bool check_mask)
 void handle_sysrq(int key)
 {
 	if (sysrq_on())
-		__handle_sysrq(key, true);
+		__handle_sysrq(key, SYSRQ_FROM_KERNEL);
 }
 EXPORT_SYMBOL(handle_sysrq);
 
@@ -661,7 +666,7 @@ static void sysrq_do_reset(unsigned long _state)
 static void sysrq_handle_reset_request(struct sysrq_state *state)
 {
 	if (state->reset_requested)
-		__handle_sysrq(sysrq_xlate[KEY_B], false);
+		__handle_sysrq(sysrq_xlate[KEY_B], SYSRQ_FROM_KERNEL);
 
 	if (sysrq_reset_downtime_ms)
 		mod_timer(&state->keyreset_timer,
@@ -812,8 +817,10 @@ static bool sysrq_handle_keypress(struct sysrq_state *sysrq,
 
 	default:
 		if (sysrq->active && value && value != 2) {
+			int from = sysrq->handle.dev->flags & INPUTDEV_FLAGS_SYNTHETIC ?
+					SYSRQ_FROM_SYNTHETIC : 0;
 			sysrq->need_reinject = false;
-			__handle_sysrq(sysrq_xlate[code], true);
+			__handle_sysrq(sysrq_xlate[code], from);
 		}
 		break;
 	}
@@ -1097,7 +1104,7 @@ static ssize_t write_sysrq_trigger(struct file *file, const char __user *buf,
 
 		if (get_user(c, buf))
 			return -EFAULT;
-		__handle_sysrq(c, false);
+		__handle_sysrq(c, SYSRQ_FROM_PROC);
 	}
 
 	return count;
diff --git a/include/linux/input.h b/include/linux/input.h
index a65e3b24fb18..8b0357175049 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -42,6 +42,7 @@ struct input_value {
  * @phys: physical path to the device in the system hierarchy
  * @uniq: unique identification code for the device (if device has it)
  * @id: id of the device (struct input_id)
+ * @flags: input device flags (SYNTHETIC, etc.)
  * @propbit: bitmap of device properties and quirks
  * @evbit: bitmap of types of events supported by the device (EV_KEY,
  *	EV_REL, etc.)
@@ -124,6 +125,8 @@ struct input_dev {
 	const char *uniq;
 	struct input_id id;
 
+	unsigned int flags;
+
 	unsigned long propbit[BITS_TO_LONGS(INPUT_PROP_CNT)];
 
 	unsigned long evbit[BITS_TO_LONGS(EV_CNT)];
@@ -190,6 +193,8 @@ struct input_dev {
 };
 #define to_input_dev(d) container_of(d, struct input_dev, dev)
 
+#define	INPUTDEV_FLAGS_SYNTHETIC	0x000000001
+
 /*
  * Verify that we are in sync with input_device_id mod_devicetable.h #defines
  */
diff --git a/include/linux/sysrq.h b/include/linux/sysrq.h
index 387fa7d05c98..f7c52a9ea394 100644
--- a/include/linux/sysrq.h
+++ b/include/linux/sysrq.h
@@ -28,6 +28,8 @@
 #define SYSRQ_ENABLE_BOOT	0x0080
 #define SYSRQ_ENABLE_RTNICE	0x0100
 
+#define SYSRQ_DISABLE_USERSPACE	0x00010000
+
 struct sysrq_key_op {
 	void (*handler)(int);
 	char *help_msg;
@@ -42,8 +44,12 @@ struct sysrq_key_op {
  * are available -- else NULL's).
  */
 
+#define SYSRQ_FROM_KERNEL	0x0001
+#define SYSRQ_FROM_PROC		0x0002
+#define SYSRQ_FROM_SYNTHETIC	0x0004
+
 void handle_sysrq(int key);
-void __handle_sysrq(int key, bool check_mask);
+void __handle_sysrq(int key, unsigned int from);
 int register_sysrq_key(int key, struct sysrq_key_op *op);
 int unregister_sysrq_key(int key, struct sysrq_key_op *op);
 struct sysrq_key_op *__sysrq_get_key_op(int key);
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index c8146d53ca67..b480cadf9272 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1970,7 +1970,7 @@ static int kdb_sr(int argc, const char **argv)
 		return KDB_ARGCOUNT;
 
 	kdb_trap_printk++;
-	__handle_sysrq(*argv[1], check_mask);
+	__handle_sysrq(*argv[1], check_mask ? SYSRQ_FROM_KERNEL : 0);
 	kdb_trap_printk--;
 
 	return 0;

[toc] | [prev] | [next] | [standalone]


#1617347 — [PATCH 10/24] hibernate: Disable when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:20 +0200
Subject[PATCH 10/24] hibernate: Disable when the kernel is locked down
Message-ID<tsZzl-7hF-49@gated-at.bofh.it>
In reply to#1617335
From: Josh Boyer <jwboyer@fedoraproject.org>

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pm@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
index a8b978c35a6a..50cca5dcb62f 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
 
 bool hibernation_available(void)
 {
-	return (nohibernate == 0);
+	return nohibernate == 0 && !kernel_is_locked_down();
 }
 
 /**

[toc] | [prev] | [next] | [standalone]


#1617348 — [PATCH 14/24] x86: Restrict MSR access when the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:30 +0200
Subject[PATCH 14/24] x86: Restrict MSR access when the kernel is locked down
Message-ID<tsZIZ-7kG-3@gated-at.bofh.it>
In reply to#1617335
From: Matthew Garrett <matthew.garrett@nebula.com>

Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode.  Based on a
patch by Kees Cook.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
cc: x86@kernel.org
---

 arch/x86/kernel/msr.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index ef688804f80d..fbcce028e502 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,9 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
 	int err = 0;
 	ssize_t bytes = 0;
 
+	if (kernel_is_locked_down())
+		return -EPERM;
+
 	if (count % 8)
 		return -EINVAL;	/* Invalid chunk size */
 
@@ -131,6 +134,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)
 			err = -EBADF;
 			break;
 		}
+		if (kernel_is_locked_down()) {
+			err = -EPERM;
+			break;
+		}
 		if (copy_from_user(&regs, uregs, sizeof regs)) {
 			err = -EFAULT;
 			break;

[toc] | [prev] | [next] | [standalone]


#1617349 — [PATCH 04/24] Enforce module signatures if the kernel is locked down

FromDavid Howells <dhowells@redhat.com>
Date2017-04-05 22:30 +0200
Subject[PATCH 04/24] Enforce module signatures if the kernel is locked down
Message-ID<tsZJ0-7kG-11@gated-at.bofh.it>
In reply to#1617335
If the kernel is locked down, require that all modules have valid
signatures that we can verify.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 kernel/module.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/module.c b/kernel/module.c
index 7eba6dea4f41..3331f2eb9b93 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2756,7 +2756,7 @@ static int module_sig_check(struct load_info *info, int flags)
 	}
 
 	/* Not having a signature is only an error if we're strict. */
-	if (err == -ENOKEY && !sig_enforce)
+	if (err == -ENOKEY && !sig_enforce && !kernel_is_locked_down())
 		err = 0;
 
 	return err;

[toc] | [prev] | [next] | [standalone]


Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.kernel


csiph-web