From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:50:37
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.
Enabling CONFIG_LOCK_DOWN_KERNEL makes lockdown mode available.
Enabling CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ will allow a SysRq combination
to lift the lockdown. On x86 this is SysRq+x. The keys must be pressed on
an attached keyboard.
Enabling CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT will cause EFI secure boot to
trigger kernel lockdown.
Inside the kernel, kernel_is_locked_down() is used to check if the kernel
is in lockdown mode.
Note that the secure boot mode entry doesn't work if the kernel is booted
from older versions of i386/x86_64 Grub as there's a bug in Grub whereby it
doesn't initialise the boot_params correctly. The incorrect initialisation
causes sanitize_boot_params() to be triggered, thereby zapping the secure
boot flag determined by the EFI boot wrapper.
A manual page, kernel_lockdown.7, is proposed, to which people will be
directed by messages in dmesg. This lists the features that are restricted
amongst other things.
I'm aware there may be things that aren't yet handled, but we can add those
later.
====================
PROPOSED MANUAL PAGE
====================
.\"
.\" Copyright (C) 2017 Red Hat, Inc. All Rights Reserved.
.\" Written by David Howells (dhowells at 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 is restricted, see man kernel_lockdown.7
.RE
.P
where X 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 things are disabled or restricted in
use. 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 memory access functions
.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
The following facilities are restricted:
.P
.RS
Only validly signed modules may be loaded.
.P
Only validly signed binaries may be kexec'd.
.P
Only validly signed device firmware may be loaded.
.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.
.RE
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH SEE ALSO
.ad l
.nh
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=efi-lock-down
Tagged thusly:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
lockdown-20171019
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 (11):
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
debugfs: Disallow use of debugfs files when the kernel is locked down
Lock down /proc/kcore
efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode
efi: Lock down the kernel if booted in secure boot mode
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 (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/msr: 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/include/asm/setup.h | 2 +
arch/x86/kernel/ioport.c | 6 +-
arch/x86/kernel/kexec-bzimage64.c | 1
arch/x86/kernel/msr.c | 7 ++
arch/x86/kernel/setup.c | 18 +-----
arch/x86/mm/testmmiotrace.c | 3 +
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/firmware/efi/Makefile | 1
drivers/firmware/efi/secureboot.c | 37 +++++++++++++
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/platform/x86/asus-wmi.c | 9 +++
drivers/scsi/eata.c | 5 +-
drivers/tty/serial/serial_core.c | 6 ++
drivers/tty/sysrq.c | 19 ++++--
fs/debugfs/file.c | 6 ++
fs/proc/kcore.c | 2 +
include/linux/efi.h | 16 +++--
include/linux/input.h | 5 ++
include/linux/kernel.h | 17 ++++++
include/linux/security.h | 8 +++
include/linux/sysrq.h | 8 ++-
kernel/debug/kdb/kdb_main.c | 2 -
kernel/kexec.c | 7 ++
kernel/kexec_file.c | 7 ++
kernel/module.c | 3 +
kernel/params.c | 26 +++++++--
kernel/power/hibernate.c | 2 -
kernel/power/user.c | 3 +
kernel/trace/bpf_trace.c | 11 ++++
security/Kconfig | 37 +++++++++++++
security/Makefile | 3 +
security/lock_down.c | 109 +++++++++++++++++++++++++++++++++++++
40 files changed, 391 insertions(+), 41 deletions(-)
create mode 100644 drivers/firmware/efi/secureboot.c
create mode 100644 security/lock_down.c
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:50:47
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 | 17 +++++++++++++
include/linux/security.h | 8 ++++++
security/Kconfig | 8 ++++++
security/Makefile | 3 ++
security/lock_down.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 96 insertions(+)
create mode 100644 security/lock_down.c
@@ -205,6 +205,14 @@ config STATIC_USERMODEHELPER_PATHIfyouwishforallusermodehelperprogramstobedisabled,specifyanemptystringhere(i.e."").+configLOCK_DOWN_KERNEL+bool"Allow the kernel to be 'locked down'"+help+Allowthekerneltobelockeddownundercertaincircumstances,for+instanceifUEFIsecurebootisenabled.Lockingdownthekernel+turnsoffvariousfeaturesthatmightotherwiseallowaccesstothe+kernelimage(eg.settingMSRregisters).+sourcesecurity/selinux/Kconfigsourcesecurity/smack/Kconfigsourcesecurity/tomoyo/Kconfig
@@ -0,0 +1,60 @@+/* Lock down the kernel+*+*Copyright(C)2016RedHat,Inc.AllRightsReserved.+*WrittenbyDavidHowells(dhowellsatredhat.com)+*+*Thisprogramisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicence+*aspublishedbytheFreeSoftwareFoundation;eitherversion+*2oftheLicence,or(atyouroption)anylaterversion.+*/++#include<linux/security.h>+#include<linux/export.h>++static__ro_after_initboolkernel_locked_down;++/*+*Putthekernelintolock-downmode.+*/+staticvoid__initlock_kernel_down(constchar*where)+{+if(!kernel_locked_down){+kernel_locked_down=true;+pr_notice("Kernel is locked down from %s; see man kernel_lockdown.7\n",+where);+}+}++staticint__initlockdown_param(char*ignored)+{+lock_kernel_down("command line");+return0;+}++early_param("lockdown",lockdown_param);++/*+*Lockthekerneldownfromveryearlyinthearchsetup.Thismusthappen+*priortothingslikeACPIbeinginitialised.+*/+void__initinit_lockdown(void)+{+#ifdef CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT+if(efi_enabled(EFI_SECURE_BOOT))+lock_kernel_down("EFI secure boot");+#endif+}++/**+*kernel_is_locked_down-Findoutifthekernelislockeddown+*@what:Tagtouseinnoticegeneratediflockdownisineffect+*/+bool__kernel_is_locked_down(constchar*what,boolfirst)+{+if(what&&first&&kernel_locked_down)+pr_notice("Lockdown: %s is restricted; see man kernel_lockdown.7\n",+what);+returnkernel_locked_down;+}+EXPORT_SYMBOL(__kernel_is_locked_down);--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: James Morris <hidden> Date: 2017-10-20 23:20:01
On Thu, 19 Oct 2017, David Howells wrote:
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>
Acked-by: James Morris <redacted>
--
James Morris
[off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:50:54
From: Kyle McMartin <redacted>
Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.
On x86_64 this is triggered with SysRq+x, but this key may not be available
on all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Signed-off-by: Kyle McMartin <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86 at kernel.org
---
arch/x86/include/asm/setup.h | 2 ++
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 +-
security/Kconfig | 15 +++++++++++++
security/lock_down.c | 48 ++++++++++++++++++++++++++++++++++++++++++
8 files changed, 92 insertions(+), 8 deletions(-)
@@ -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 */
@@ -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");/**Shouldwecheckforenabledoperations(/proc/sysrq-trigger*shouldnot)andistheinvokedoperationenabled?*/-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);
@@ -213,6 +213,21 @@ config LOCK_DOWN_KERNELturnsoffvariousfeaturesthatmightotherwiseallowaccesstothekernelimage(eg.settingMSRregisters).+configALLOW_LOCKDOWN_LIFT+bool+help+Allowthelockdownonakerneltobelifted,therebyrestoringthe+abilityofuserspacetoaccessthekernelimage(eg.bySysRq+xunder+x86).++configALLOW_LOCKDOWN_LIFT_BY_SYSRQ+bool"Allow the kernel lockdown to be lifted by SysRq"+depends onMAGIC_SYSRQ+help+Allowthelockdownonakerneltobelifted,bypressingaSysRqkey+combinationonawiredkeyboard.++sourcesecurity/selinux/Kconfigsourcesecurity/smack/Kconfigsourcesecurity/tomoyo/Kconfig
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Randy Dunlap <hidden> Date: 2017-10-19 17:20:33
On 10/19/17 07:50, David Howells wrote:
From: Kyle McMartin <redacted>
Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.
On x86_64 this is triggered with SysRq+x, but this key may not be available
on all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Signed-off-by: Kyle McMartin <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86 at kernel.org
---
arch/x86/include/asm/setup.h | 2 ++
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 +-
security/Kconfig | 15 +++++++++++++
security/lock_down.c | 48 ++++++++++++++++++++++++++++++++++++++++++
8 files changed, 92 insertions(+), 8 deletions(-)
+ x86).
+
+config ALLOW_LOCKDOWN_LIFT_BY_SYSRQ
+ bool "Allow the kernel lockdown to be lifted by SysRq"
+ depends on MAGIC_SYSRQ
+ help
+ Allow the lockdown on a kernel to be lifted, by pressing a SysRq key
+ combination on a wired keyboard.
+
+
source security/selinux/Kconfig
source security/smack/Kconfig
source security/tomoyo/Kconfig
+
+/*
+ * Allow lockdown to be lifted by pressing something like SysRq+x (and not by
+ * echoing the appropriate letter into the sysrq-trigger file).
+ */
+#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT_BY_KEY
is that the same as: CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ ?
tested?
BY_SYSRQ
--
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 22:12:35
Randy Dunlap [off-list ref] wrote:
quoted
+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: on
quoted
+ x86).
I'll just get rid of this config option, I think - it doesn't make anything
available outside of lock_down.c.
quoted
+#ifdef CONFIG_ALLOW_LOCKDOWN_LIFT_BY_KEY
is that the same as: CONFIG_ALLOW_LOCKDOWN_LIFT_BY_SYSRQ ?
tested?
My test machine doesn't have a physical keyboard attached, but you're right.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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)
lockdown_lift_sysrq_op.help_msg[5] = LOCKDOWN_LIFT_KEY;
^~~~~~~~~~~~~~~~~
security/lock_down.c:100:40: note: each undeclared identifier is reported only once for each function it appears in
--
Thiago Jung Bauermann
IBM Linux Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-07 22:56:55
Thiago Jung Bauermann [off-list ref] 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)
lockdown_lift_sysrq_op.help_msg[5] = LOCKDOWN_LIFT_KEY;
^~~~~~~~~~~~~~~~~
security/lock_down.c:100:40: note: each undeclared identifier is reported only once for each function it appears in
I've added an arch dependency in the Kconfig file in my local branch. I'll
try to get it pushed again.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:02
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 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -2781,7 +2781,8 @@ 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("Loading of unsigned modules"))err=0;returnerr;--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
@@ -2781,7 +2781,8 @@ 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("Loading of unsigned modules"))err=0;returnerr;--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: James Morris <hidden> Date: 2017-10-20 23:21:36
On Thu, 19 Oct 2017, David Howells wrote:
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>
Reviewed-by: James Morris <redacted>
--
James Morris
[off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-10-19 at 15:50 +0100, David Howells wrote:
quoted hunk
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 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
@@ -2781,7 +2781,8 @@ 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("Loading of unsigned modules"))
?
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 -
!is_ima_appraise_enabled().
Mimi
?
err = 0;
return err;
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-30 17:00:38
Mimi Zohar [off-list ref] 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 -
!is_ima_appraise_enabled().
IMA can only be used with finit_module()?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Corrected Matthew Garrett's email address. ?Cc'ed Bruno Meneguele]
On Mon, 2017-10-30 at 17:00 +0000, David Howells wrote:
Mimi Zohar [off-list ref] wrote:
quoted
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 -
!is_ima_appraise_enabled().
IMA can only be used with finit_module()?
Yes, without the file descriptor, IMA-appraisal can't access the
xattrs.?
You should really look at Bruno's patches, which are in my next
branch:
8168913c50d5 "ima: check signature enforcement against cmdline param instead of CONFIG"
404090509894 module: export module signature enforcement status
Can we get an Ack on the module one?
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-02 17:22:41
Hi Mimi,
I've altered this patch to allow for IMA appraisal on finit_module(). See the
attached.
David
---
commit c0d5336356004e7543314e388755a00e725521da
Author: David Howells [off-list ref]
Date: Wed May 24 14:56:01 2017 +0100
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 [off-list ref]
Reviewed-by: "Lee, Chun-Yi" [off-list ref]
Reviewed-by: James Morris [off-list ref]
@@ -2781,13 +2783,16 @@ 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&&+(!can_do_ima_check||!is_ima_appraise_enabled())&&+!kernel_is_locked_down("Loading of unsigned modules"))err=0;returnerr;}#else /* !CONFIG_MODULE_SIG */-staticintmodule_sig_check(structload_info*info,intflags)+staticintmodule_sig_check(structload_info*info,intflags,+boolcan_do_ima_check){return0;}
@@ -3630,13 +3635,13 @@ static int unknown_module_param_cb(char *param, char *val, const char *modname,/* Allocate and load the module: note that size of section 0 is alwayszero,andwerelyonthisforoptionalsections.*/staticintload_module(structload_info*info,constchar__user*uargs,-intflags)+intflags,boolcan_do_ima_check){structmodule*mod;longerr;char*after_dashes;-err=module_sig_check(info,flags);+err=module_sig_check(info,flags,can_do_ima_check);if(err)gotofree_copy;
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-11-02 at 17:22 +0000, David Howells wrote:
quoted hunk
#ifdef CONFIG_MODULE_SIG
-static int module_sig_check(struct load_info *info, int flags)
+static int module_sig_check(struct load_info *info, int flags,
+ bool can_do_ima_check)
{
int err = -ENOKEY;
const unsigned long markerlen = sizeof(MODULE_SIG_STRING) - 1;
@@ -2781,13 +2783,16 @@ 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 &&+ (!can_do_ima_check || !is_ima_appraise_enabled()) &&+ !kernel_is_locked_down("Loading of unsigned modules"))
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 required as well.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-02 21:30:16
Mimi Zohar [off-list ref] 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 required as well.
I guess I don't need to put in any support for IMA here, then, and you've
taken care of it in your patchset such that it won't actually go into
module_sig_check() in that case (or will at least return immediately).
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-11-02 at 21:30 +0000, David Howells wrote:
Mimi Zohar [off-list ref] wrote:
quoted
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 required as well.
I guess I don't need to put in any support for IMA here, then, and you've
taken care of it in your patchset such that it won't actually go into
module_sig_check() in that case (or will at least return immediately).
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 && is_ima_appraise_enabled())
? ? ? ? ? ? ? ? err = 0;
Mimi?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-02 22:01:12
Mimi Zohar [off-list ref] 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 && is_ima_appraise_enabled())
? ? ? ? ? ? ? ? err = 0;
I'm not sure where you want to put that, but I can't just do this:
/* Not having a signature is only an error if we're strict. */
if (err == -ENOKEY && !sig_enforce &&
(!can_do_ima_check || !is_ima_appraise_enabled()) &&
!kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
else if (can_do_ima_check && is_ima_appraise_enabled())
err = 0;
because that'll print out a message in lockdown mode saying that you're not
allowed to do that and then maybe do it anyway.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-11-02 at 22:01 +0000, David Howells wrote:
Mimi Zohar [off-list ref] wrote:
quoted
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 && is_ima_appraise_enabled())
? ? ? ? ? ? ? ? err = 0;
I'm not sure where you want to put that, but I can't just do this:
/* Not having a signature is only an error if we're strict. */
if (err == -ENOKEY && !sig_enforce &&
(!can_do_ima_check || !is_ima_appraise_enabled()) &&
The above IMA checks aren't needed here.
!kernel_is_locked_down("Loading of unsigned modules"))
err = 0;
else if (can_do_ima_check && is_ima_appraise_enabled())
err = 0;
because that'll print out a message in lockdown mode saying that you're not
allowed to do that and then maybe do it anyway.
Then at least for now, document that even though kernel modules might
be signed and verified by IMA-appraisal, that in lockdown mode they
also require an appended signature.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:08
From: Matthew Garrett <redacted>
Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions. Prevent this when the
kernel has been locked down.
Signed-off-by: Matthew Garrett <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/char/mem.c | 6 ++++++
1 file changed, 6 insertions(+)
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info@ http://vger.kernel.org/majordomo-info.html
Hi David,
Thanks for you send out this series.
On Thu, Oct 19, 2017 at 03:51:02PM +0100, David Howells wrote:
From: Matthew Garrett <redacted>
Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions. Prevent this when the
kernel has been locked down.
Signed-off-by: Matthew Garrett <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
I have reviewed and tested this patch. Please feel free to add:
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Thanks a lot!
Joey Lee
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: James Morris <hidden> Date: 2017-10-20 23:22:09
On Thu, 19 Oct 2017, David Howells wrote:
From: Matthew Garrett <redacted>
Allowing users to write to address space makes it possible for the kernel to
be subverted, avoiding module loading restrictions. Prevent this when the
kernel has been locked down.
Signed-off-by: Matthew Garrett <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <redacted>
--
James Morris
[off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-23 14:34:22
I think I should replace this patch with the attached. This will prevent
/dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
read, write and ioctl.
David
---
commit e68daa2256986932b9a7d6709cf9e24b30d93583
Author: Matthew Garrett [off-list ref]
Date: Wed May 24 14:56:02 2017 +0100
Restrict /dev/{mem,kmem,port} when the kernel is locked down
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being 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 [off-list ref]
Signed-off-by: David Howells [off-list ref]
Reviewed-by: "Lee, Chun-Yi" [off-list ref]
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David?
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 policy change with
secure boot ?
Thanks,
Ethan
On Mon, Oct 23, 2017 at 10:34 PM, David Howells [off-list ref] wrote:
quoted hunk
I think I should replace this patch with the attached. This will prevent
/dev/mem, /dev/kmem and /dev/port from being *opened*, and thereby preventing
read, write and ioctl.
David
---
commit e68daa2256986932b9a7d6709cf9e24b30d93583
Author: Matthew Garrett [off-list ref]
Date: Wed May 24 14:56:02 2017 +0100
Restrict /dev/{mem,kmem,port} when the kernel is locked down
Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.
Disallow /dev/mem and /dev/kmem from being 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 [off-list ref]
Signed-off-by: David Howells [off-list ref]
Reviewed-by: "Lee, Chun-Yi" [off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-24 14:56:53
Ethan Zhao [off-list ref] 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 policy change with
secure boot ?
I removed readability on /dev/mem, /dev/kmem and /proc/kcore so that userspace
can't use this to gain access to cryptographic material in use by the kernel.
Readability was removed on /dev/port because reading from an I/O port register
might have a side effect or might allow you to snoop h/w interactions, such as
keyboard input.
I can provide an additional config option to allow /dev/mem and similar to
remain readable - but it needs to be a temporary affair.
I can also log accesses to these interfaces so that we can find out what
breaks and fix it.
Note that dmidecode doesn't necessarily use /dev/mem:
[root at andromeda ~]# strace -f -eopen dmidecode >/dev/null
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/sys/firmware/dmi/tables/smbios_entry_point", O_RDONLY) = 3
open("/sys/firmware/dmi/tables/DMI", O_RDONLY) = 3
+++ exited with 0 +++
Indeed, my Fedora 24 test system boots without a /dev/mem file being present
(I'm not sure *why* /dev/mem isn't present, but I hadn't noticed till now).
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:17
From: Matthew Garrett <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <redacted>
cc: kexec at lists.infradead.org
---
kernel/kexec.c | 7 +++++++
1 file changed, 7 insertions(+)
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 19, 2017 at 03:51:09PM +0100, David Howells wrote:
From: Matthew Garrett <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <redacted>
I have reviewed and tested this patch. Please feel free to add:
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Thanks a lot!
Joey Lee
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: James Morris <hidden> Date: 2017-10-20 23:23:26
On Thu, 19 Oct 2017, David Howells wrote:
From: Matthew Garrett <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <redacted>
cc: kexec at lists.infradead.org
Reviewed-by: James Morris <redacted>
--
James Morris
[off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:25
From: Dave Young <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
arch/x86/kernel/kexec-bzimage64.c | 1 +
1 file changed, 1 insertion(+)
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,if(efi_enabled(EFI_OLD_MEMMAP))return0;+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;--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Oct 19, 2017 at 03:51:20PM +0100, David Howells wrote:
From: Dave Young <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
I have reviewed and tested this patch. Please feel free to add:
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Thanks a lot!
Joey Lee
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,if(efi_enabled(EFI_OLD_MEMMAP))return0;+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;--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:33
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
kernel/kexec_file.c | 7 +++++++
1 file changed, 7 insertions(+)
@@ -255,6 +255,13 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,if(!capable(CAP_SYS_BOOT)||kexec_load_disabled)return-EPERM;+/* Don't permit images to be loaded into trusted kernels if we're not+*goingtoverifythesignatureonthem+*/+if(!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG)&&+kernel_is_locked_down("kexec of unsigned images"))+return-EPERM;+/* Make sure we have a legal set of flags */if(flags!=(flags&KEXEC_FILE_FLAGS))return-EINVAL;--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: James Morris <hidden> Date: 2017-10-20 23:26:40
On Thu, 19 Oct 2017, David Howells wrote:
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Reviewed-by: James Morris <redacted>
--
James Morris
[off-list ref]
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
quoted hunk
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
kernel/kexec_file.c | 7 +++++++
1 file changed, 7 insertions(+)
@@ -255,6 +255,13 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,if(!capable(CAP_SYS_BOOT)||kexec_load_disabled)return-EPERM;+/* Don't permit images to be loaded into trusted kernels if we're not+*goingtoverifythesignatureonthem+*/+if(!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG)&&+kernel_is_locked_down("kexec of unsigned images"))+return-EPERM;+/* Make sure we have a legal set of flags */if(flags!=(flags&KEXEC_FILE_FLAGS))return-EINVAL;--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
Thanks a lot!
Joey Lee
---
From 274a2125132ba5aff49e4ccd167f52982732361f Mon Sep 17 00:00:00 2001
From: "Lee, Chun-Yi" <jlee@suse.com>
Date: Thu, 26 Oct 2017 15:24:50 +0800
Subject: [PATCH] kexec_file: The integrity must be checked when the kernel is
locked down
When KEXEC_VERIFY_SIG and IMA appraise are not enabled, kernel should
not allow that the image to be loaded by kexec_file systemcall when the
kernel is locked down.
The original code was showed in Matthew's patch but not in the later
patch set:
https://lkml.org/lkml/2015/3/13/778
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
---
kernel/kexec_file.c | 8 ++++++++
1 file changed, 8 insertions(+)
@@ -255,6 +255,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,if(!capable(CAP_SYS_BOOT)||kexec_load_disabled)return-EPERM;+/* Don't permit images to be loaded into trusted kernels if we're not+*goingtochecktheintegrityonthem+*/+if(!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG)&&+!is_ima_appraise_enabled()&&+kernel_is_locked_down("kexec of unsigned images"))+return-EPERM;+/* Make sure we have a legal set of flags */if(flags!=(flags&KEXEC_FILE_FLAGS))return-EINVAL;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
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.
The IMA "secure_boot" policy can be specified on the boot command line
as ima_policy="secure_boot". ?It requires kernel modules, firmware,
kexec kernel image and the IMA custom policy to be signed. ?In
lockdown mode, these rules are enabled by default and added to the
custom policy.
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
kernel_read_file_from_fd() calls the security_kernel_read_file() and
security_kernel_post_read_file() hooks, which call ima_read_file() and
ima_post_read_file() respectively.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote:
On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote:
quoted
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
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.
The IMA "secure_boot" policy can be specified on the boot command line
as ima_policy="secure_boot". ?It requires kernel modules, firmware,
kexec kernel image and the IMA custom policy to be signed. ?In
lockdown mode, these rules are enabled by default and added to the
custom policy.
quoted
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
kernel_read_file_from_fd() calls the security_kernel_read_file() and
security_kernel_post_read_file() hooks, which call ima_read_file() and
ima_post_read_file() respectively.
Hm, with "lockdown" enabled on the boot command line, I'm now able to
do the kexec load, but not the unload. :/ ? After the kexec load with
the "--reuse-cmdline" option, the system reboots, but isn't in
"lockdown" mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote:
On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote:
quoted
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
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.
The IMA "secure_boot" policy can be specified on the boot command line
as ima_policy="secure_boot". ?It requires kernel modules, firmware,
kexec kernel image and the IMA custom policy to be signed. ?In
lockdown mode, these rules are enabled by default and added to the
custom policy.
quoted
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
kernel_read_file_from_fd() calls the security_kernel_read_file() and
security_kernel_post_read_file() hooks, which call ima_read_file() and
ima_post_read_file() respectively.
Hm, with "lockdown" enabled on the boot command line, I'm now able to
do the kexec load, but not the unload. :/ ? After the kexec load with
I have tried on Qemu with OVMF, I can load and unload second kernel by
kexec tool (on openSUSE is in kexec-tools RPM):
# kexec -u -s
I add -s for using kexec-load-file, and I signed kernel by pesign.
the "--reuse-cmdline" option, the system reboots, but isn't in
"lockdown" mode.
Either enabling secure boot in EFI firmware or using _lockdown_ kernel
parameter, the second kernel can be locked down on my OVMF VM.
I used following commands:
# kexec -s -l /boot/vmlinuz-4.14.0-rc2-default+ --append="$(cat /proc/cmdline)" --initrd=/boot/initrd-4.14.0-rc2-default+
# umount -a; mount -o remount,ro /
# kexec -e
The kernel source is from David's linux-fs git with lockdown-20171026 tag.
The kernel is also signed by pesign.
Regards
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 27, 2017 at 03:32:26PM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote:
quoted
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
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.
The IMA "secure_boot" policy can be specified on the boot command line
as ima_policy="secure_boot". ?It requires kernel modules, firmware,
kexec kernel image and the IMA custom policy to be signed. ?In
lockdown mode, these rules are enabled by default and added to the
custom policy.
quoted
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
kernel_read_file_from_fd() calls the security_kernel_read_file() and
security_kernel_post_read_file() hooks, which call ima_read_file() and
ima_post_read_file() respectively.
Hm, with "lockdown" enabled on the boot command line, I'm now able to
do the kexec load, but not the unload. :/ ? After the kexec load with
I have tried on Qemu with OVMF, I can load and unload second kernel by
kexec tool (on openSUSE is in kexec-tools RPM):
# kexec -u -s
Thanks, I left off the "-s" option, causing it to fail. ?This is the
correct behavior. ?So both with/without the "-s" option are working
properly.
I add -s for using kexec-load-file, and I signed kernel by pesign.
quoted
the "--reuse-cmdline" option, the system reboots, but isn't in
"lockdown" mode.
Either enabling secure boot in EFI firmware or using _lockdown_ kernel
parameter, the second kernel can be locked down on my OVMF VM.
I used following commands:
# kexec -s -l /boot/vmlinuz-4.14.0-rc2-default+ --append="$(cat /proc/cmdline)" --initrd=/boot/initrd-4.14.0-rc2-default+
# umount -a; mount -o remount,ro /I'
# kexec -e
The kernel source is from David's linux-fs git with lockdown-20171026 tag.
The kernel is also signed by pesign.
Yes, based on the patches in David's tree, "lockdown" is being carried
to the target OS properly.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-10-26 at 10:17 -0400, Mimi Zohar wrote:
On Thu, 2017-10-26 at 15:42 +0800, joeyli wrote:
quoted
Hi Mimi,
Thank you for reviewing.
On Mon, Oct 23, 2017 at 11:54:43AM -0400, Mimi Zohar wrote:
quoted
On Thu, 2017-10-19 at 15:51 +0100, David Howells wrote:
quoted
From: Chun-Yi Lee <redacted>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
The patch title and description needs to be updated to refer to
lockdown, not securelevel.
As previously mentioned the last time these patches were posted, this
leaves out testing to see if the integrity subsystem is enabled.
Commit 503ceaef8e2e "ima: define a set of appraisal rules requiring
file signatures" was upstreamed. ?An additional patch could force
these rules to be added to the custom policy, if lockdown is enabled.
?This and other patches in this series could then check to see if
is_ima_appraise_enabled() is true.
Mimi
I have updated the patch title and description, and I also added
is_ima_appraise_enabled() as the following. Is it good to you?
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.
The IMA "secure_boot" policy can be specified on the boot command line
as ima_policy="secure_boot". ?It requires kernel modules, firmware,
kexec kernel image and the IMA custom policy to be signed. ?In
lockdown mode, these rules are enabled by default and added to the
custom policy.
quoted
On the other hand, I am not good on IMA. I have traced the code path
in kimage_file_prepare_segments(). Looks that the READING_KEXEC_IMAGE
doesn't show in selinux_kernel_read_file(). Where is the exact code
in IMA for checking the signature when loading crash kernel file?
kernel_read_file_from_fd() calls the security_kernel_read_file() and
security_kernel_post_read_file() hooks, which call ima_read_file() and
ima_post_read_file() respectively.
Hm, with "lockdown" enabled on the boot command line, I'm now able to
do the kexec load, but not the unload. :/ ? After the kexec load with
the "--reuse-cmdline" option, the system reboots, but isn't in
"lockdown" mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What happens if the file in question is being accessed from a filesystem that
doesn't have xattrs and doesn't provide support for appraisal? Is it rejected
outright or just permitted?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What happens if the file in question is being accessed from a filesystem that
doesn't have xattrs and doesn't provide support for appraisal? Is it rejected
outright or just permitted?
IMA-appraisal returns -EACCES for any error, including lack of xattr
support.
Thiago Bauermann posted the "Appended signatures support for IMA
appraisal" patch set. ?This patch set allows the current kernel module
appended signature format to be used for verifying the kernel image.
?Once that patch set is upstreamed, we'll be able to update the IMA
"secure_boot" policy to permit appended signatures.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-26 15:02:29
joeyli [off-list ref] 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 appraise is enabled.
I think the commit message needs expansion as to why it's okay. Can you also
do it as an additional patch rather than altering the original IMA-less patch
7?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Cc'ing Matthew Garrett]
On Thu, 2017-10-26 at 16:02 +0100, David Howells wrote:
joeyli [off-list ref] wrote:
quoted
+ 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 appraise is enabled.
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. ?With the "ima: require
secure_boot rules in lockdown mode" patch, the "lockdown" mode would
enable IMA-appraisal's secure_boot policy, without requiring the boot
command line option. ?It would also add the secure_boot rules to the
custom policy, so that if the builtin policy is replaced with a custom
policy, the "secure_boot" policy would still be enforced.
Other patches in this patch series need to be updated as well to check
if IMA-appraisal is enabled.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-30 15:49:52
Mimi Zohar [off-list ref] 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 boot command
line? Can you sum up both cases in a paragraph I can add to the patch
description?
Other patches in this patch series need to be updated as well to check
if IMA-appraisal is enabled.
Which exactly? I've added your "!is_ima_appraise_enabled() &&" line to
kexec_file() and module_sig_check(). Anything else?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2017-10-30 at 15:49 +0000, David Howells wrote:
Mimi Zohar [off-list ref] wrote:
quoted
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 boot command
line? Can you sum up both cases in a paragraph I can add to the patch
description?
The other patch automatically enables "secure_boot" for lockdown mode.
So there is no need to specify "secure_boot" on the boot command line.
?Reordering the patches so that the other patch comes before any call
to is_ima_appraise_enabled() will simplify this patch description.
quoted
Other patches in this patch series need to be updated as well to check
if IMA-appraisal is enabled.
Which exactly? I've added your "!is_ima_appraise_enabled() &&" line to
kexec_file() and module_sig_check(). Anything else?
load_module(), which calls module_sig_check(), is called by both the
old and new kernel module syscalls. ?IMA is only on the new syscall.
?Did you differentiate between the kernel module syscalls?
There doesn't seem to be any other patches affected. ?That said, the
IMA "secure_boot" policy is more stringent than what you have without
it. ?For example, with the "secure_boot" policy enabled, firwmware
needs to be signed as well. ?At some point, we'll want to also require
the initramfs be signed as well.
Both methods work independently of each other, but there needs to be
better coordination for when both methods are enabled at the same time
(eg. are both signatures required?).
For testing purposes, you can use the same certs/signing_key to sign
the kexec image, kernel modules and firmware, by loading the
signing_key on the .ima keyring. ?Using evmctl, sign the files
(eg.?evmctl ima_sign -a sha256 -k certs/signing_key.pem??--imasig
/boot/<vmlinuz>).
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-02 17:00:14
Mimi Zohar [off-list ref] 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 modules. (Unless you mean just for the installer)
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-26 14:51:49
Mimi Zohar [off-list ref] 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, though at this point I'm leaning towards
passing the current series to James for security/next and then passing your
patch along afterwards, if that's okay with you. It should still get in the
next merge window if that's the case.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-11-02 17:30:02
Hi Mimi,
I've adjusted the patch as below.
David
---
commit bf33218ad2bf04f1b92f5c32499ab906f107864c
Author: Chun-Yi Lee [off-list ref]
Date: Wed May 24 14:56:03 2017 +0100
kexec_file: Restrict at runtime if the kernel is locked down
When KEXEC_VERIFY_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down unless IMA can be used
to validate the image.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett [off-list ref]
Signed-off-by: Chun-Yi Lee [off-list ref]
Signed-off-by: David Howells [off-list ref]
Reviewed-by: James Morris [off-list ref]
cc: kexec at lists.infradead.org
@@ -255,6 +255,14 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,if(!capable(CAP_SYS_BOOT)||kexec_load_disabled)return-EPERM;+/* Don't permit images to be loaded into trusted kernels if we're not+*goingtoverifythesignatureonthem+*/+if(!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG)&&+!is_ima_appraise_enabled()&&+kernel_is_locked_down("kexec of unsigned images"))+return-EPERM;+/* Make sure we have a legal set of flags */if(flags!=(flags&KEXEC_FILE_FLAGS))return-EINVAL;--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Howells <dhowells@redhat.com> Date: 2017-10-19 14:51:39
From: Josh Boyer <redacted>
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 <redacted>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pm at vger.kernel.org
---
kernel/power/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html