* [PATCH 09/27] hibernate: Disable when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
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>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pm@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
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 abef759de7c8..802795becb88 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("Hibernation");
}
/**
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 10/27] uswsusp: Disable when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel. Disable this if the kernel
is locked down.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: linux-pm@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/power/user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 2d8b60a3c86b..0305d513c274 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -52,6 +52,9 @@ static int snapshot_open(struct inode *inode, struct file *filp)
if (!hibernation_available())
return -EPERM;
+ if (kernel_is_locked_down("/dev/snapshot"))
+ return -EPERM;
+
lock_system_sleep();
if (!atomic_add_unless(&snapshot_device_available, -1, 0)) {
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 15/27] acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Josh Boyer <jwboyer@redhat.com>
This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware . Reject
the option when the kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: Dave Young <dyoung@redhat.com>
cc: linux-acpi@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/acpi/osl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..3e44cef7a0cd 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -194,7 +194,7 @@ acpi_physical_address __init acpi_os_get_root_pointer(void)
acpi_physical_address pa;
#ifdef CONFIG_KEXEC
- if (acpi_rsdp)
+ if (acpi_rsdp && !kernel_is_locked_down("ACPI RSDP specification"))
return acpi_rsdp;
#endif
pa = acpi_arch_get_root_pointer();
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 14/27] ACPI: Limit access to custom_method when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/acpi/custom_method.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index 4451877f83b6..ac8a90dc7096 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -29,6 +29,9 @@ static ssize_t cm_write(struct file *file, const char __user * user_buf,
struct acpi_table_header table;
acpi_status status;
+ if (kernel_is_locked_down("ACPI custom methods"))
+ return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 16/27] acpi: Disable ACPI table override if the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Linn Crosetto <linn@hpe.com>
From the kernel documentation (initrd_table_override.txt):
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
to override nearly any ACPI table provided by the BIOS with an
instrumented, modified one.
When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space. ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/acpi/tables.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 48eabb6c2d4f..f3b4117cd8f3 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -531,6 +531,11 @@ void __init acpi_table_upgrade(void)
if (table_nr == 0)
return;
+ if (kernel_is_locked_down("ACPI table override")) {
+ pr_notice("kernel is locked down, ignoring table override\n");
+ return;
+ }
+
acpi_tables_addr =
memblock_find_in_range(0, ACPI_TABLE_UPGRADE_MAX_PHYS,
all_tables_size, PAGE_SIZE);
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 17/27] acpi: Disable APEI error injection if the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Linn Crosetto <linn@hpe.com>
ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features. If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.
Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors. This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.
While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.
Signed-off-by: Linn Crosetto <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/acpi/apei/einj.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index fcccbfdbdd1a..9fe6bbab2e7d 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -518,6 +518,9 @@ static int einj_error_inject(u32 type, u32 flags, u64 param1, u64 param2,
int rc;
u64 base_addr, size;
+ if (kernel_is_locked_down("ACPI error injection"))
+ return -EPERM;
+
/* If user manually set "flags", make sure it is legal */
if (flags && (flags &
~(SETWA_FLAGS_APICID|SETWA_FLAGS_MEM|SETWA_FLAGS_PCIE_SBDF)))
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 18/27] Prohibit PCMCIA CIS storage when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.
Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/pcmcia/cistpl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index ac0672b8dfca..8adf092d0e18 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -1578,6 +1578,9 @@ static ssize_t pccard_store_cis(struct file *filp, struct kobject *kobj,
struct pcmcia_socket *s;
int error;
+ if (kernel_is_locked_down("Direct PCMCIA CIS storage"))
+ return -EPERM;
+
s = to_socket(container_of(kobj, struct device, kobj));
if (off)
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 19/27] Lock down TIOCSSERIAL
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port. This only appears to be an issue for the serial
drivers that use the core serial code. All other drivers seem to either
ignore attempts to change port/irq or give an error.
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jiri Slaby <jslaby@suse.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/tty/serial/serial_core.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index d4cca5bdaf1c..04534877b575 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -842,6 +842,12 @@ static int uart_set_info(struct tty_struct *tty, struct tty_port *port,
new_flags = (__force upf_t)new_info->flags;
old_custom_divisor = uport->custom_divisor;
+ if ((change_port || change_irq) &&
+ kernel_is_locked_down("Using TIOCSSERIAL to change device addresses, irqs and dma channels")) {
+ retval = -EPERM;
+ goto exit;
+ }
+
if (!capable(CAP_SYS_ADMIN)) {
retval = -EPERM;
if (change_irq || change_port ||
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 21/27] x86/mmiotrace: Lock down the testmmiotrace module
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space.
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Howells <dhowells@redhat.com
cc: Thomas Gleixner <tglx@linutronix.de>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
arch/x86/mm/testmmiotrace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index f6ae6830b341..bbaad357f5d7 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -115,6 +115,9 @@ static int __init init(void)
{
unsigned long size = (read_far) ? (8 << 20) : (16 << 10);
+ if (kernel_is_locked_down("MMIO trace testing"))
+ return -EPERM;
+
if (mmio_address == 0) {
pr_err("you have to use the module argument mmio_address.\n");
pr_err("DO NOT LOAD THIS MODULE UNLESS YOU REALLY KNOW WHAT YOU ARE DOING!\n");
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 22/27] Lock down /proc/kcore
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
fs/proc/kcore.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index bbcc185062bb..d50ebfbf3dbb 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -518,6 +518,8 @@ read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t *fpos)
static int open_kcore(struct inode *inode, struct file *filp)
{
+ if (kernel_is_locked_down("/proc/kcore"))
+ return -EPERM;
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 23/27] Lock down kprobes
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Disallow the creation of kprobes when the kernel is locked down by
preventing their registration. This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/kprobes.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index f4ddfdd2d07e..6f66cca8e2c6 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1552,6 +1552,9 @@ int register_kprobe(struct kprobe *p)
struct module *probed_mod;
kprobe_opcode_t *addr;
+ if (kernel_is_locked_down("Use of kprobes"))
+ return -EPERM;
+
/* Adjust probe address from symbol */
addr = kprobe_addr(p);
if (IS_ERR(addr))
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 24/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.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 and kernel memory to be altered without
restriction.
Completely prohibit the use of BPF when the kernel is locked down.
Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/bpf/syscall.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index b155cd17c1bd..2cde39a875aa 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -2585,6 +2585,9 @@ SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, siz
if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
return -EPERM;
+ if (kernel_is_locked_down("BPF"))
+ return -EPERM;
+
err = bpf_check_uarg_tail_zero(uattr, sizeof(attr), size);
if (err)
return err;
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 26/27] debugfs: Restrict debugfs when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Disallow opening of debugfs files that might be used to muck around when
the kernel is locked down as various drivers give raw access to hardware
through debugfs. Given the effort of auditing all 2000 or so files and
manually fixing each one as necessary, I've chosen to apply a heuristic
instead. The following changes are made:
(1) chmod and chown are disallowed on debugfs objects (though the root dir
can be modified by mount and remount, but I'm not worried about that).
(2) When the kernel is locked down, only files with the following criteria
are permitted to be opened:
- The file must have mode 00444
- The file must not have ioctl methods
- The file must not have mmap
(3) When the kernel is locked down, files may only be opened for reading.
Normal device interaction should be done through configfs, sysfs or a
miscdev, not debugfs.
Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.
I would actually prefer to lock down all files by default and have the
the files unlocked by the creator. This is tricky to manage correctly,
though, as there are 19 creation functions and ~1600 call sites (some of
them in loops scanning tables).
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Andy Shevchenko <andy.shevchenko@gmail.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
fs/debugfs/file.c | 28 ++++++++++++++++++++++++++++
fs/debugfs/inode.c | 30 ++++++++++++++++++++++++++++--
2 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 4fce1da7db23..c33042c1eff3 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -136,6 +136,25 @@ void debugfs_file_put(struct dentry *dentry)
}
EXPORT_SYMBOL_GPL(debugfs_file_put);
+/*
+ * Only permit access to world-readable files when the kernel is locked down.
+ * We also need to exclude any file that has ways to write or alter it as root
+ * can bypass the permissions check.
+ */
+static bool debugfs_is_locked_down(struct inode *inode,
+ struct file *filp,
+ const struct file_operations *real_fops)
+{
+ if ((inode->i_mode & 07777) == 0444 &&
+ !(filp->f_mode & FMODE_WRITE) &&
+ !real_fops->unlocked_ioctl &&
+ !real_fops->compat_ioctl &&
+ !real_fops->mmap)
+ return false;
+
+ return kernel_is_locked_down("debugfs");
+}
+
static int open_proxy_open(struct inode *inode, struct file *filp)
{
struct dentry *dentry = F_DENTRY(filp);
@@ -147,6 +166,11 @@ static int open_proxy_open(struct inode *inode, struct file *filp)
return r == -EIO ? -ENOENT : r;
real_fops = debugfs_real_fops(filp);
+
+ r = -EPERM;
+ if (debugfs_is_locked_down(inode, filp, real_fops))
+ goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -272,6 +296,10 @@ static int full_proxy_open(struct inode *inode, struct file *filp)
return r == -EIO ? -ENOENT : r;
real_fops = debugfs_real_fops(filp);
+ r = -EPERM;
+ if (debugfs_is_locked_down(inode, filp, real_fops))
+ goto out;
+
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index 13b01351dd1c..4daec17b8215 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -32,6 +32,31 @@ static struct vfsmount *debugfs_mount;
static int debugfs_mount_count;
static bool debugfs_registered;
+/*
+ * Don't allow access attributes to be changed whilst the kernel is locked down
+ * so that we can use the file mode as part of a heuristic to determine whether
+ * to lock down individual files.
+ */
+static int debugfs_setattr(struct dentry *dentry, struct iattr *ia)
+{
+ if ((ia->ia_valid & (ATTR_MODE | ATTR_UID | ATTR_GID)) &&
+ kernel_is_locked_down("debugfs"))
+ return -EPERM;
+ return simple_setattr(dentry, ia);
+}
+
+static const struct inode_operations debugfs_file_inode_operations = {
+ .setattr = debugfs_setattr,
+};
+static const struct inode_operations debugfs_dir_inode_operations = {
+ .lookup = simple_lookup,
+ .setattr = debugfs_setattr,
+};
+static const struct inode_operations debugfs_symlink_inode_operations = {
+ .get_link = simple_get_link,
+ .setattr = debugfs_setattr,
+};
+
static struct inode *debugfs_get_inode(struct super_block *sb)
{
struct inode *inode = new_inode(sb);
@@ -356,6 +381,7 @@ static struct dentry *__debugfs_create_file(const char *name, umode_t mode,
inode->i_mode = mode;
inode->i_private = data;
+ inode->i_op = &debugfs_file_inode_operations;
inode->i_fop = proxy_fops;
dentry->d_fsdata = (void *)((unsigned long)real_fops |
DEBUGFS_FSDATA_IS_REAL_FOPS_BIT);
@@ -513,7 +539,7 @@ struct dentry *debugfs_create_dir(const char *name, struct dentry *parent)
return failed_creating(dentry);
inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
- inode->i_op = &simple_dir_inode_operations;
+ inode->i_op = &debugfs_dir_inode_operations;
inode->i_fop = &simple_dir_operations;
/* directory inodes start off with i_nlink == 2 (for "." entry) */
@@ -608,7 +634,7 @@ struct dentry *debugfs_create_symlink(const char *name, struct dentry *parent,
return failed_creating(dentry);
}
inode->i_mode = S_IFLNK | S_IRWXUGO;
- inode->i_op = &simple_symlink_inode_operations;
+ inode->i_op = &debugfs_symlink_inode_operations;
inode->i_link = link;
d_instantiate(dentry, inode);
return end_creating(dentry);
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 27/27] lockdown: Print current->comm in restriction messages
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Print the content of current->comm in messages generated by lockdown to
indicate a restriction that was hit. This makes it a bit easier to find
out what caused the message.
The message now patterned something like:
Lockdown: <comm>: <what> is restricted; see man kernel_lockdown.7
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
security/lock_down.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/lock_down.c b/security/lock_down.c
index cfbc2c39712b..5243b55b3c1f 100644
--- a/security/lock_down.c
+++ b/security/lock_down.c
@@ -58,8 +58,8 @@ void __init init_lockdown(void)
bool __kernel_is_locked_down(const char *what, bool first)
{
if (what && first && kernel_locked_down)
- pr_notice("Lockdown: %s is restricted; see man kernel_lockdown.7\n",
- what);
+ pr_notice("Lockdown: %s: %s is restricted; see man kernel_lockdown.7\n",
+ current->comm, what);
return kernel_locked_down;
}
EXPORT_SYMBOL(__kernel_is_locked_down);
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 25/27] Lock down perf
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
Disallow the use of certain perf facilities that might allow userspace to
access kernel data.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/events/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 3cd13a30f732..7748c6f39992 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -10461,6 +10461,11 @@ SYSCALL_DEFINE5(perf_event_open,
return -EINVAL;
}
+ if ((attr.sample_type & PERF_SAMPLE_REGS_INTR) &&
+ kernel_is_locked_down("PERF_SAMPLE_REGS_INTR"))
+ /* REGS_INTR can leak data, lockdown must prevent this */
+ return -EPERM;
+
/* Only privileged users can get physical addresses */
if ((attr.sample_type & PERF_SAMPLE_PHYS_ADDR) &&
perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 20/27] Lock down module params that specify hardware parameters (eg. ioport)
From: Matthew Garrett @ 2019-03-06 23:59 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: David Howells <dhowells@redhat.com>
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>
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/params.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/kernel/params.c b/kernel/params.c
index ce89f757e6da..8ac751c938f8 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -108,13 +108,19 @@ 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_notice("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("Command line-specified device addresses, irqs and dma channels"))
+ return false;
+ return true;
}
static int parse_one(char *param,
@@ -144,8 +150,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(¶ms[i]);
- err = params[i].ops->set(val, ¶ms[i]);
+ if (param_check_unsafe(¶ms[i], doing))
+ err = params[i].ops->set(val, ¶ms[i]);
+ else
+ err = -EPERM;
kernel_param_unlock(params[i].mod);
return err;
}
@@ -553,6 +561,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,
@@ -565,8 +579,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;
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 13/27] x86/msr: Restrict MSR access when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
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.
MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
arch/x86/kernel/msr.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index 4588414e2561..f5a2cf07972f 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,11 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
int err = 0;
ssize_t bytes = 0;
+ if (kernel_is_locked_down("Direct MSR access")) {
+ pr_info("Direct access to MSR %x\n", reg);
+ return -EPERM;
+ }
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
@@ -135,6 +140,11 @@ static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)
err = -EFAULT;
break;
}
+ if (kernel_is_locked_down("Direct MSR access")) {
+ pr_info("Direct access to MSR %x\n", regs[1]); /* Display %ecx */
+ err = -EPERM;
+ break;
+ }
err = wrmsr_safe_regs_on_cpu(cpu, regs);
if (err)
break;
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 12/27] x86: Lock down IO port access when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.
This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
arch/x86/kernel/ioport.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 0fe1c8782208..abc702a6ae9c 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -31,7 +31,8 @@ long ksys_ioperm(unsigned long from, unsigned long num, int turn_on)
if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
return -EINVAL;
- if (turn_on && !capable(CAP_SYS_RAWIO))
+ if (turn_on && (!capable(CAP_SYS_RAWIO) ||
+ kernel_is_locked_down("ioperm")))
return -EPERM;
/*
@@ -126,7 +127,8 @@ SYSCALL_DEFINE1(iopl, unsigned int, level)
return -EINVAL;
/* Trying to gain more privileges? */
if (level > old) {
- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) ||
+ kernel_is_locked_down("iopl"))
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 11/27] PCI: Lock down BAR access when the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
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 <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pci@vger.kernel.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
drivers/pci/pci-sysfs.c | 9 +++++++++
drivers/pci/proc.c | 9 ++++++++-
drivers/pci/syscall.c | 3 ++-
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..40c14574fcf8 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -905,6 +905,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("Direct PCI access"))
+ return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1167,6 +1170,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
enum pci_mmap_state mmap_type;
struct resource *res = &pdev->resource[bar];
+ if (kernel_is_locked_down("Direct PCI access"))
+ return -EPERM;
+
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
return -EINVAL;
@@ -1242,6 +1248,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("Direct PCI access"))
+ 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 6fa1627ce08d..1549cdd0710e 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -117,6 +117,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("Direct PCI access"))
+ return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -196,6 +199,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("Direct PCI access"))
+ return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -237,7 +243,8 @@ 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 = 0, res_bit = IORESOURCE_MEM;
- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) ||
+ kernel_is_locked_down("Direct PCI access"))
return -EPERM;
if (fpriv->mmap_state == pci_mmap_io) {
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index d96626c614f5..b8a08d3166a1 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -90,7 +90,8 @@ 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("Direct PCI access"))
return -EPERM;
dev = pci_get_domain_bus_and_slot(0, bus, dfn);
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 08/27] kexec_file: Restrict at runtime if the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Jiri Bohac <jbohac@suse.cz>
When KEXEC_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down.
[Modified by David Howells to fit with modifications to the previous patch
and to return -EPERM if the kernel is locked down for consistency with
other lockdowns. Modified by Matthew Garrett to remove the IMA
integration, which will be replaced by integrating with the IMA
architecture policy patches.]
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
cc: Chun-Yi Lee <jlee@suse.com>
cc: kexec@lists.infradead.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 67f3a866eabe..0cfe4f6f7f85 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -239,6 +239,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
}
ret = 0;
+
+ if (kernel_is_locked_down(reason)) {
+ ret = -EPERM;
+ goto out;
+ }
+
break;
/* All other errors are fatal, including nomem, unparseable
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PATCH 05/27] kexec_load: Disable at runtime if the kernel is locked down
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
In-Reply-To: <20190306235913.6631-1-matthewgarrett@google.com>
From: Matthew Garrett <mjg59@srcf.ucam.org>
The kexec_load() syscall 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_load() in this situation.
This does not affect kexec_file_load() syscall which can check for a
signature on the image to be booted.
Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: kexec@lists.infradead.org
Signed-off-by: Matthew Garrett <matthewgarrett@google.com>
---
kernel/kexec.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 68559808fdfa..8ea0ce31271f 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -207,6 +207,13 @@ static inline int kexec_load_check(unsigned long nr_segments,
if (result < 0)
return result;
+ /*
+ * kexec can be used to circumvent module loading restrictions, so
+ * prevent loading in that case
+ */
+ if (kernel_is_locked_down("kexec of unsigned images"))
+ return -EPERM;
+
/*
* Verify we have a legal set of flags
* This leaves us room for future extensions.
--
2.21.0.352.gf09ad66450-goog
^ permalink raw reply related
* [PULL REQUEST] Kernel lockdown patches for 5.2
From: Matthew Garrett @ 2019-03-06 23:58 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
Hi James,
This patchset introduces an optional kernel lockdown feature,
intended to strengthen the boundary between UID 0 and the kernel. When
enabled and active (by enabling the config option and passing the
"lockdown" option on the kernel command line), various pieces of
kernel functionality are restricted. Applications that rely on
low-level access to either hardware or the kernel may cease working as
a result - therefore this should not be enabled without appropriate
evaluation beforehand.
The majority of mainstream distributions have been carrying variants
of this patchset for many years now, so there's value in providing a
unified upstream implementation to reduce the delta. This PR probably
doesn't meet every distribution requirement, but gets us much closer
to not requiring external patches.
This PR is mostly the same as the previous attempt, but with the
following changes:
1) The integration between EFI secure boot and the lockdown state has
been removed
2) A new CONFIG_KERNEL_LOCK_DOWN_FORCE kconfig option has been added,
which will always enable lockdown regardless of the kernel command
line
3) The integration with IMA has been dropped for now. IMA is in the
process of adding support for architecture-specific policies that will
interact correctly with the lockdown feature, and a followup patch will
integrate that so we don't end up with an ordering dependency on the
merge
The following changes since commit 468e91cecb3218afd684b8c422490dfebe0691bb:
keys: fix missing __user in KEYCTL_PKEY_QUERY (2019-03-04 15:48:37 -0800)
are available in the Git repository at:
https://github.com/mjg59/linux lock_down
for you to fetch changes up to 3d53449e0ac1df8cfdcc1ec48dc9cb622f220300:
lockdown: Print current->comm in restriction messages (2019-03-06 13:32:19 -0800)
----------------------------------------------------------------
Dave Young (1):
Copy secure_boot flag in boot params across kexec reboot
David Howells (12):
Add the ability to lock down access to the running kernel image
Enforce module signatures if the kernel is locked down
Prohibit PCMCIA CIS storage when the kernel is locked down
Lock down TIOCSSERIAL
Lock down module params that specify hardware parameters (eg. ioport)
x86/mmiotrace: Lock down the testmmiotrace module
Lock down /proc/kcore
Lock down kprobes
bpf: Restrict kernel image access functions when the kernel is locked down
Lock down perf
debugfs: Restrict debugfs when the kernel is locked down
lockdown: Print current->comm in restriction messages
Jiri Bohac (2):
kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG and KEXEC_SIG_FORCE
kexec_file: Restrict at runtime if the kernel is locked down
Josh Boyer (2):
hibernate: Disable when the kernel is locked down
acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down
Kyle McMartin (1):
Add a SysRq option to lift kernel lockdown
Linn Crosetto (2):
acpi: Disable ACPI table override if the kernel is locked down
acpi: Disable APEI error injection if the kernel is locked down
Matthew Garrett (7):
Restrict /dev/{mem,kmem,port} when the kernel is locked down
kexec_load: Disable at runtime if the kernel is locked down
uswsusp: Disable when the kernel is locked down
PCI: Lock down BAR access when the kernel is locked down
x86: Lock down IO port access when the kernel is locked down
x86/msr: Restrict MSR access when the kernel is locked down
ACPI: Limit access to custom_method when the kernel is locked down
arch/x86/Kconfig | 20 +++++--
arch/x86/include/asm/setup.h | 2 +
arch/x86/kernel/ioport.c | 6 +-
arch/x86/kernel/kexec-bzimage64.c | 1 +
arch/x86/kernel/msr.c | 10 ++++
arch/x86/mm/testmmiotrace.c | 3 +
crypto/asymmetric_keys/verify_pefile.c | 4 +-
drivers/acpi/apei/einj.c | 3 +
drivers/acpi/custom_method.c | 3 +
drivers/acpi/osl.c | 2 +-
drivers/acpi/tables.c | 5 ++
drivers/char/mem.c | 2 +
drivers/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/tty/serial/serial_core.c | 6 ++
drivers/tty/sysrq.c | 19 ++++--
fs/debugfs/file.c | 28 +++++++++
fs/debugfs/inode.c | 30 +++++++++-
fs/proc/kcore.c | 2 +
include/linux/input.h | 5 ++
include/linux/kernel.h | 17 ++++++
include/linux/kexec.h | 4 +-
include/linux/security.h | 9 ++-
include/linux/sysrq.h | 8 ++-
kernel/bpf/syscall.c | 3 +
kernel/debug/kdb/kdb_main.c | 2 +-
kernel/events/core.c | 5 ++
kernel/kexec.c | 7 +++
kernel/kexec_file.c | 54 ++++++++++++++---
kernel/kprobes.c | 3 +
kernel/module.c | 39 +++++++++---
kernel/params.c | 26 ++++++--
kernel/power/hibernate.c | 2 +-
kernel/power/user.c | 3 +
security/Kconfig | 24 ++++++++
security/Makefile | 3 +
security/lock_down.c | 106 +++++++++++++++++++++++++++++++++
40 files changed, 447 insertions(+), 44 deletions(-)
create mode 100644 security/lock_down.c
^ permalink raw reply
* [PATCH] security: keys: Kconfig: pedantic cleanup
From: Enrico Weigelt, metux IT consult @ 2019-03-06 18:57 UTC (permalink / raw)
To: linux-kernel; +Cc: dhowells, keyrings, linux-security-module
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
---
security/keys/Kconfig | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index 6462e66..6594149 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -90,14 +90,14 @@ config ENCRYPTED_KEYS
If you are unsure as to whether this is required, answer N.
config KEY_DH_OPERATIONS
- bool "Diffie-Hellman operations on retained keys"
- depends on KEYS
- select CRYPTO
- select CRYPTO_HASH
- select CRYPTO_DH
- help
- This option provides support for calculating Diffie-Hellman
- public keys and shared secrets using values stored as keys
- in the kernel.
-
- If you are unsure as to whether this is required, answer N.
+ bool "Diffie-Hellman operations on retained keys"
+ depends on KEYS
+ select CRYPTO
+ select CRYPTO_HASH
+ select CRYPTO_DH
+ help
+ This option provides support for calculating Diffie-Hellman
+ public keys and shared secrets using values stored as keys
+ in the kernel.
+
+ If you are unsure as to whether this is required, answer N.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v7 0/7] Allow initializing the kernfs node's secctx based on its parent
From: Casey Schaufler @ 2019-03-06 18:04 UTC (permalink / raw)
To: Ondrej Mosnacek, selinux, Paul Moore
Cc: Stephen Smalley, Linux Security Module list, Tejun Heo,
Serge E . Hallyn, Greg Kroah-Hartman, James Morris, linux-fsdevel,
cgroups
In-Reply-To: <CAFqZXNs28QAxHA3=vECuG17TQ-be0ywS=r9S48q_KNBYpzgJLg@mail.gmail.com>
On 3/6/2019 7:54 AM, Ondrej Mosnacek wrote:
> On Fri, Feb 22, 2019 at 3:57 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>> TL;DR:
>> This series adds a new security hook that allows to initialize the security
>> context of kernfs properly, taking into account the parent context (and
>> possibly other attributes). Kernfs nodes require special handling here, since
>> they are not bound to specific inodes/superblocks, but instead represent the
>> backing tree structure that is used to build the VFS tree when the kernfs
>> tree is mounted.
>>
>> Changes in v7:
>> - simplify the new security hook's interface
>> - rather than trying to extract kernfs data into common structures, just
>> pass the kernfs nodes themselves and add helper functions to
>> <linux/kernfs.h> for accessing their security xattrs
>> - in case other LSMs need more kernfs node attributes than the file mode
>> (uid/gid/...), they can simply add new helpers to <linux/kernfs.h> as
>> needed
>> - refactor "kernfs: use simple_xattrs for security attributes" to keep using
>> a single common simple_xattrs structure
>> - turns out having two separate simple_xattrs wouldn't work right (see
>> the definition of simple_xattr_list() in fs/xattr.c)
>> - drop unnecessary initializations from inode_doinit_use_xattr()
>> - move the IOP_XATTR check out of inode_doinit_use_xattr()
>> - add two kernfs cleanup patches
>> - these could be applied independently, but the rest of the patches depend on
>> them, so I'd rather they stay bundled with the rest to avoid cross-tree
>> conflicts
>>
>> v6: https://lore.kernel.org/selinux/20190214095015.16032-1-omosnace@redhat.com/T/
>> Changes in v6:
>> - remove copy-pasted duplicate macro definition
>>
>> v5: https://lore.kernel.org/selinux/20190205110638.30782-1-omosnace@redhat.com/T/
>> Changes in v5:
>> - fix misplaced semicolon detected by 0day robot
>>
>> v4: https://lore.kernel.org/selinux/20190205085915.5183-1-omosnace@redhat.com/T/
>> Changes in v4:
>> - reorder and rename hook arguments
>> - avoid allocating kernfs_iattrs unless needed
>>
>> v3: https://lore.kernel.org/selinux/20190130114150.27807-1-omosnace@redhat.com/T/
>> Changes in v3:
>> - rename the hook to "kernfs_init_security"
>> - change the hook interface to simply pass pointers to struct iattr and
>> struct simple_xattrs of both the new node and its parent
>> - add full security xattr support to kernfs (and fixup SELinux behavior
>> to handle it properly)
>>
>> v2: https://lore.kernel.org/selinux/20190109162830.8309-1-omosnace@redhat.com/T/
>> Changes in v2:
>> - add docstring for the new hook in union security_list_options
>> - initialize *ctx to NULL and *ctxlen to 0 in case the hook is not
>> implemented
>>
>> v1: https://lore.kernel.org/selinux/20190109091028.24485-1-omosnace@redhat.com/T/
>>
>> The kernfs nodes initially do not store any security context and rely on
>> the LSM to assign some default context to inodes created over them. Kernfs
>> inodes, however, allow setting an explicit context via the *setxattr(2)
>> syscalls, in which case the context is stored inside the kernfs node's
>> internal structure.
>>
>> SELinux (and possibly other LSMs) initialize the context of newly created
>> FS objects based on the parent object's context (usually the child inherits
>> the parent's context, unless the policy dictates otherwise). This is done
>> by hooking the creation of the new inode corresponding to the newly created
>> file/directory via security_inode_init_security() (most filesystems always
>> create a fresh inode when a new FS object is created). However, kernfs nodes
>> can be created "behind the scenes" while the filesystem is not mounted
>> anywhere and thus no inodes can exist for them yet.
>>
>> Therefore, to allow maintaining similar behavior for kernfs nodes, a new
>> LSM hook is needed, which will allow initializing the kernfs node's
>> security context based on its own attributes and those of the parent's
>> node.
>>
>> The main motivation for this change is that the userspace users of cgroupfs
>> (which is built on kernfs) expect the usual security context inheritance
>> to work under SELinux (see [1] and [2]). This functionality is required for
>> better confinement of containers under SELinux.
>>
>> Patch 1/7 simplifies the kernfs_iattrs structure and patch 2/7 optimizes
>> kernfs to not allocate kernfs_iattrs when getting the value of an xattr.
>>
>> Patch 3/7 changes SELinux to fetch security context from extended
>> attributes on kernfs filesystems, falling back to genfs-defined context
>> if that fails. Without this patch the 4/7 would be a regression for
>> SELinux (due to the removal of ...notifysecctx() call.
>>
>> Patch 4/7 implements full security xattr support in kernfs using
>> simple_xattrs; patch 5/7 adds the new LSM hook; patch 6/7 implements the
>> new hook in SELinux; and patch 7/7 modifies kernfs to call the new hook
>> on new node creation.
>>
>> Testing:
>> - passed the reproducer from the commit message of the last patch
>> - passed SELinux testsuite on Fedora Rawhide (x86_64) when applied on top
>> of current Rawhide kernel (5.0.0-0.rc7.git2.1) [3]
>> - including the new proposed selinux-testsuite subtest [4] (adapted
>> from the reproducer)
>>
>> [1] https://github.com/SELinuxProject/selinux-kernel/issues/39
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1553803
>> [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=32963825
>> [4] https://github.com/SELinuxProject/selinux-testsuite/pull/48
>>
>> Ondrej Mosnacek (7):
>> kernfs: clean up struct kernfs_iattrs
>> kernfs: do not alloc iattrs in kernfs_xattr_get
>> selinux: try security xattr after genfs for kernfs filesystems
>> kernfs: use simple_xattrs for security attributes
>> LSM: add new hook for kernfs node initialization
>> selinux: implement the kernfs_init_security hook
>> kernfs: initialize security of newly created nodes
>>
>> fs/kernfs/dir.c | 28 ++--
>> fs/kernfs/inode.c | 166 +++++++++------------
>> fs/kernfs/kernfs-internal.h | 8 +-
>> fs/kernfs/symlink.c | 4 +-
>> include/linux/kernfs.h | 15 ++
>> include/linux/lsm_hooks.h | 13 ++
>> include/linux/security.h | 9 ++
>> security/security.c | 6 +
>> security/selinux/hooks.c | 223 +++++++++++++++++++---------
>> security/selinux/include/security.h | 1 +
>> 10 files changed, 290 insertions(+), 183 deletions(-)
>>
>> --
>> 2.20.1
> Ping about this series... Casey, are you OK with this new version?
I'm still not wildly enthusiastic about it, but I can't
offer a better solution right now. You can add my
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
^ permalink raw reply
* Re: [RFC PATCH 0/2] Create CAAM HW key in linux keyring and use in dmcrypt
From: David Howells @ 2019-03-06 17:29 UTC (permalink / raw)
To: Franck LENORMAND
Cc: dhowells, linux-kernel, linux-security-module, keyrings,
horia.geanta, silvano.dininno, agk, snitzer, dm-devel, jmorris,
serge
In-Reply-To: <1551456599-10603-1-git-send-email-franck.lenormand@nxp.com>
Franck LENORMAND <franck.lenormand@nxp.com> wrote:
> The capacity to generate or load keys already available in the Linux key
> retention service does not allows to exploit CAAM capabilities hence we
> need to create a new key_type. The new key type "caam_tk" allows to:
> - Create a black key from random
> - Create a black key from a red key
> - Load a black blob to retrieve the black key
Is it possible that this could be done through an existing key type, such as
the asymmetric, trusted or encrypted key typed?
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox