* [PATCH 22/27] Lock down kprobes
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Alexei Starovoitov,
Matthew Garrett, Naveen N . Rao, Anil S Keshavamurthy, davem,
Masami Hiramatsu
In-Reply-To: <20190325220954.29054-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>
Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: davem@davemloft.net
Cc: Masami Hiramatsu <mhiramat@kernel.org>
---
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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 24/27] Lock down perf
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Matthew Garrett,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo
In-Reply-To: <20190325220954.29054-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>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
---
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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 26/27] lockdown: Print current->comm in restriction messages
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells, Matthew Garrett
In-Reply-To: <20190325220954.29054-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 18d8776a4d02..ee00ca2677e7 100644
--- a/security/lock_down.c
+++ b/security/lock_down.c
@@ -53,8 +53,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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 27/27] kexec: Allow kexec_file() with appropriate IMA policy when locked down
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Matthew Garrett,
Matthew Garrett, Mimi Zohar, Dmitry Kasatkin, linux-integrity
In-Reply-To: <20190325220954.29054-1-matthewgarrett@google.com>
Systems in lockdown mode should block the kexec of untrusted kernels.
For x86 and ARM we can ensure that a kernel is trustworthy by validating
a PE signature, but this isn't possible on other architectures. On those
platforms we can use IMA digital signatures instead. Add a function to
determine whether IMA has or will verify signatures for a given event type,
and if so permit kexec_file() even if the kernel is otherwise locked down.
This is restricted to cases where CONFIG_INTEGRITY_TRUSTED_KEYRING is set
in order to prevent an attacker from loading additional keys at runtime.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: linux-integrity@vger.kernel.org
---
include/linux/ima.h | 9 ++++++
kernel/kexec_file.c | 7 +++-
security/integrity/ima/ima.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/integrity/ima/ima_policy.c | 50 +++++++++++++++++++++++++++++
5 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/include/linux/ima.h b/include/linux/ima.h
index b5e16b8c50b7..05921227d700 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -127,4 +127,13 @@ static inline int ima_inode_removexattr(struct dentry *dentry,
return 0;
}
#endif /* CONFIG_IMA_APPRAISE */
+
+#if defined(CONFIG_IMA_APPRAISE) && defined(CONFIG_INTEGRITY_TRUSTED_KEYRING)
+extern bool ima_appraise_signature(enum kernel_read_file_id func);
+#else
+static inline bool ima_appraise_kexec_signature(enum kernel_read_file_id func)
+{
+ return false;
+}
+#endif /* CONFIG_IMA_APPRAISE && CONFIG_INTEGRITY_TRUSTED_KEYRING */
#endif /* _LINUX_IMA_H */
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 0cfe4f6f7f85..8ffa4b75c620 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -240,7 +240,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd,
ret = 0;
- if (kernel_is_locked_down(reason)) {
+ /* If IMA is guaranteed to appraise a signature on the kexec
+ * image, permit it even if the kernel is otherwise locked
+ * down.
+ */
+ if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
+ kernel_is_locked_down(reason)) {
ret = -EPERM;
goto out;
}
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index cc12f3449a72..fe03cc6f1ca4 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -115,6 +115,8 @@ struct ima_kexec_hdr {
u64 count;
};
+extern const int read_idmap[];
+
#ifdef CONFIG_HAVE_IMA_KEXEC
void ima_load_kexec_buffer(void);
#else
diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
index 4ffac4f5c647..106f06dee9d1 100644
--- a/security/integrity/ima/ima_main.c
+++ b/security/integrity/ima/ima_main.c
@@ -442,7 +442,7 @@ int ima_read_file(struct file *file, enum kernel_read_file_id read_id)
return 0;
}
-static const int read_idmap[READING_MAX_ID] = {
+const int read_idmap[READING_MAX_ID] = {
[READING_FIRMWARE] = FIRMWARE_CHECK,
[READING_FIRMWARE_PREALLOC_BUFFER] = FIRMWARE_CHECK,
[READING_MODULE] = MODULE_CHECK,
diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
index 122797023bdb..f8f1cdb74a4f 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1341,3 +1341,53 @@ int ima_policy_show(struct seq_file *m, void *v)
return 0;
}
#endif /* CONFIG_IMA_READ_POLICY */
+
+#if defined(CONFIG_IMA_APPRAISE) && defined(CONFIG_INTEGRITY_TRUSTED_KEYRING)
+/*
+ * ima_appraise_signature: whether IMA will appraise a given function using
+ * an IMA digital signature. This is restricted to cases where the kernel
+ * has a set of built-in trusted keys in order to avoid an attacker simply
+ * loading additional keys.
+ */
+bool ima_appraise_signature(enum kernel_read_file_id id)
+{
+ struct ima_rule_entry *entry;
+ bool found = false;
+ enum ima_hooks func;
+
+ if (id >= READING_MAX_ID)
+ return false;
+
+ func = read_idmap[id] ?: FILE_CHECK;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(entry, ima_rules, list) {
+ if (entry->action != APPRAISE)
+ continue;
+
+ /*
+ * A generic entry will match, but otherwise require that it
+ * match the func we're looking for
+ */
+ if (entry->func && entry->func != func)
+ continue;
+
+ /*
+ * We require this to be a digital signature, not a raw IMA
+ * hash.
+ */
+ if (entry->flags & IMA_DIGSIG_REQUIRED)
+ found = true;
+
+ /*
+ * We've found a rule that matches, so break now even if it
+ * didn't require a digital signature - a later rule that does
+ * won't override it, so would be a false positive.
+ */
+ break;
+ }
+
+ rcu_read_unlock();
+ return found;
+}
+#endif /* CONFIG_IMA_APPRAISE && CONFIG_INTEGRITY_TRUSTED_KEYRING */
--
2.21.0.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 25/27] debugfs: Restrict debugfs when the kernel is locked down
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Andy Shevchenko,
acpi4asus-user, platform-driver-x86, Matthew Garrett,
Thomas Gleixner, Greg Kroah-Hartman, Matthew Garrett
In-Reply-To: <20190325220954.29054-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>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Alexei Starovoitov,
netdev, Chun-Yi Lee, Daniel Borkmann, Matthew Garrett
In-Reply-To: <20190325220954.29054-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>
Cc: Daniel Borkmann <daniel@iogearbox.net>
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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 21/27] Lock down /proc/kcore
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, James Morris,
Matthew Garrett
In-Reply-To: <20190325220954.29054-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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 18/27] Lock down TIOCSSERIAL
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Greg Kroah-Hartman,
Jiri Slaby, linux-serial, Matthew Garrett
In-Reply-To: <20190325220954.29054-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>
Cc: linux-serial@vger.kernel.org
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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PATCH 07/27] kexec_file: Restrict at runtime if the kernel is locked down
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris
Cc: linux-security-module, linux-kernel, dhowells, Jiri Bohac, kexec,
Matthew Garrett
In-Reply-To: <20190325220954.29054-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: 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.392.gf8f6787159e-goog
^ permalink raw reply related
* [PULL REQUEST] Lockdown patches for 5.2
From: Matthew Garrett @ 2019-03-25 22:09 UTC (permalink / raw)
To: jmorris; +Cc: linux-security-module, linux-kernel, dhowells
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 1c57935ab108280aa79fe4420d4bc13e19bd38e2:
kexec: Allow kexec_file() with appropriate IMA policy when locked down (2019-03-25 15:00:35 -0700)
This version replaces the original IMA integration with a new approach
tied to IMA architecture policy. It also drops the sysrq patch for now,
since that primarily makes sense in the context of lockdown policy being
automatically enabled based on boot state.
----------------------------------------------------------------
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
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,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
kexec: Allow kexec_file() with appropriate IMA policy when locked down
arch/x86/Kconfig | 20 +++++++++---
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/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 ++++
fs/debugfs/file.c | 28 ++++++++++++++++
fs/debugfs/inode.c | 30 +++++++++++++++--
fs/proc/kcore.c | 2 ++
include/linux/ima.h | 9 +++++
include/linux/kernel.h | 17 ++++++++++
include/linux/kexec.h | 4 +--
include/linux/security.h | 9 ++++-
kernel/bpf/syscall.c | 3 ++
kernel/events/core.c | 5 +++
kernel/kexec.c | 7 ++++
kernel/kexec_file.c | 59 +++++++++++++++++++++++++++++----
kernel/kprobes.c | 3 ++
kernel/module.c | 39 ++++++++++++++++++----
kernel/params.c | 26 ++++++++++++---
kernel/power/hibernate.c | 2 +-
kernel/power/user.c | 3 ++
security/Kconfig | 15 +++++++++
security/Makefile | 3 ++
security/integrity/ima/ima.h | 2 ++
security/integrity/ima/ima_main.c | 2 +-
security/integrity/ima/ima_policy.c | 50 ++++++++++++++++++++++++++++
security/lock_down.c | 60 ++++++++++++++++++++++++++++++++++
38 files changed, 430 insertions(+), 37 deletions(-)
create mode 100644 security/lock_down.c
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
From: Dan Williams @ 2019-03-25 21:33 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, linux-security-module, stable, James Bottomley,
Mimi Zohar, David Howells, James Morris, Serge E. Hallyn,
open list:KEYS-TRUSTED, open list
In-Reply-To: <20190325144735.30443-1-jarkko.sakkinen@linux.intel.com>
On Mon, Mar 25, 2019 at 7:48 AM Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
> key type callbacks and exported functions to fail when a TPM is not
> available.
>
> Cc: Dan Williams <dan.j.williams@intel.com>
Reported-and-tested-by: Dan Williams <dan.j.williams@intel.com>
Thanks Jarkko!
^ permalink raw reply
* Re: [PATCH] tomoyo: Add a kernel config option for fuzzing testing.
From: Tetsuo Handa @ 2019-03-25 21:09 UTC (permalink / raw)
To: James Morris
Cc: Paul Moore, linux-security-module, Dmitry Vyukov, syzbot, syzbot
In-Reply-To: <CAHC9VhRMcdk5yAc0xoJ1nMfj7KAcktKmQ1GSYP2C4yRzqS9PFA@mail.gmail.com>
James,
I think that nothing prevents this patch.
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Tetsuo Handa @ 2019-03-25 21:05 UTC (permalink / raw)
To: James Morris, Randy Dunlap
Cc: Linus Torvalds, Linux List Kernel Mailing, linux-security-module,
Kees Cook
In-Reply-To: <alpine.LRH.2.21.1903260607500.13529@namei.org>
On 2019/03/26 4:08, James Morris wrote:
> On Sun, 24 Mar 2019, Randy Dunlap wrote:
>
>> On 3/24/19 2:26 PM, Linus Torvalds wrote:
>>> Well, we're a week away from the merge window close, and here's rc2.
>>> Things look fairly normal, but honestly, rc2 is usually too early to
>>> tell. People haven't necessarily had time to notice problems yet.
>>> Which is just another way of saying "please test harder".
>>>
>>> Nothing particularly stands out. Yes, we had some fixes for the new
>>> io_ring code for issues that were discussed when merging it. Other
>>> than that, worth noting is that the bulk of the patches are for
>>> tooling, not the core kernel. In fact, about two thirds of the patch
>>> is just for the tools/ subdirectory, most of it due to some late perf
>>> tool updates. The people involved promise they're done.
>>
>> Hmph. I'm still looking for the patch that restores the various
>> CONFIG_DEFAULT_<security> kconfig options to be merged.
>>
>> https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
>>
>> since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.
>
> AFAICT we don't have a finalized version of the patch yet.
>
> Kees?
>
As far as I can tell, Kees's comment
It breaks the backward-compat for the "security=" line. If a system is
booted with CONFIG_LSM="minors...,apparmor" and "security=selinux",
neither apparmor nor selinux will be initialized. The logic on
"security=..." depends on the other LSMs being present in the list.
was just a confusion, and I think that this version can become
the finalized version.
From 72f5f21b800c87f9ec3600f6e3acfb654690d8f0 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Tue, 26 Mar 2019 05:56:30 +0900
Subject: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed
CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from
security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a
default value. That commit expected that existing users (upgrading from
Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with
their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But
since users might forget to edit CONFIG_LSM value, this patch revives
the choice (only for providing the default value for CONFIG_LSM) in order
to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their
old kernel configs.
Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
---
security/Kconfig | 37 ++++++++++++++++++++++++++++++++++++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/security/Kconfig b/security/Kconfig
index 1d6463f..2f29805 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,9 +239,44 @@ source "security/safesetid/Kconfig"
source "security/integrity/Kconfig"
+choice
+ prompt "Default security module [superseded by 'Ordered list of enabled LSMs' below]"
+ default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
+ default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
+ default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
+ default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
+ default DEFAULT_SECURITY_DAC
+
+ help
+ This choice is there only for converting CONFIG_DEFAULT_SECURITY in old
+ kernel config to CONFIG_LSM in new kernel config. Don't change this choice
+ unless you are creating a fresh kernel config, for this choice will be
+ ignored after CONFIG_LSM is once defined.
+
+ config DEFAULT_SECURITY_SELINUX
+ bool "SELinux" if SECURITY_SELINUX=y
+
+ config DEFAULT_SECURITY_SMACK
+ bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
+
+ config DEFAULT_SECURITY_TOMOYO
+ bool "TOMOYO" if SECURITY_TOMOYO=y
+
+ config DEFAULT_SECURITY_APPARMOR
+ bool "AppArmor" if SECURITY_APPARMOR=y
+
+ config DEFAULT_SECURITY_DAC
+ bool "Unix Discretionary Access Controls"
+
+endchoice
+
config LSM
string "Ordered list of enabled LSMs"
- default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
+ default "yama,loadpin,safesetid,integrity,selinux" if DEFAULT_SECURITY_SELINUX
+ default "yama,loadpin,safesetid,integrity,smack" if DEFAULT_SECURITY_SMACK
+ default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
+ default "yama,loadpin,safesetid,integrity,apparmor" if DEFAULT_SECURITY_APPARMOR
+ default "yama,loadpin,safesetid,integrity"
help
A comma-separated list of LSMs, in initialization order.
Any LSMs left off this list will be ignored. This can be
--
1.8.3.1
^ permalink raw reply related
* Re: Repost: Missing security_mmap_file() in remap_file_pages syscall
From: Stephen Smalley @ 2019-03-25 19:53 UTC (permalink / raw)
To: TongZhang, LKML, linux-security-module
Cc: akpm, mhocko, dan.j.williams, rientjes, aarcange, dave,
kirill.shutemov, Shen Wenbo
In-Reply-To: <A6FCC3DA-C72C-4B59-A27E-E91F85949608@vt.edu>
On 3/25/19 1:33 PM, TongZhang wrote:
> Dear Kernel Developers,
>
> We’d like to bring this up for a discussion again.
>
> Several months ago we posted an email discussing a case where remap_file_pages() has no security_mmap_file() check.
> At that time we were told that do_mmap_pgoff() will base the new VMA permission on the old one.
> But somehow we still think the check is needed, for the reason that the advisory could first do a
> mmap() which can pass SELinux check then remap using a completely different file or region of file,
> which could possibly pose a risk.
I don't see an issue there. The incoming prot value from userspace is
required to be zero (otherwise remap_file_pages returns -EINVAL), so the
prot passed to do_mmap_pgoff() is entirely computed based on the
existing vma flags. The file is likewise obtained from the existing
vma. Any flags supplied by the caller other than MAP_NONBLOCK are
ignored. MAP_SHARED is always set in the flags passed to
do_mmap_pgoff(), and the existing vma was required to have VM_SHARED set
or remap_file_pages() would have returned -EINVAL. If it spans more
than one vma, their files and flags must match. It appears that all of
the inputs relevant to selinux_mmap_file() are necessarily the same as
they would have been when creating the original vma. The same appears
to also be true for other security modules IIUC.
>
> Thanks,
> - Tong
>
> The original post is pasted below:
>
> 8<—————————————————————————————
> [1.] One line summary of the problem:
>
> Possible missing security_mmap_file() in remap_file_pages
>
> [2.] Full description of the problem/report:
>
> We noticed remap_file_pages syscall uses do_mmap_pgoff without LSM check: security_mmap_file().
>
> This system call passed user controllable parameters to do_mmap_pgoff().
>
> We think that this LSM check should be added in order to be consistent with other cases,
> for example:
> in system call mmap_pgoff(), shmat(), they all have security_mmap_file() check before calling
> do_mmap_pgoff().
>
> [3.] Keywords: LSM check
> [4.] Kernel information
> [4.1] Kernel Version: 4.14.61
>
> 8<—————————————————————————————
>
>
>
>
>
^ permalink raw reply
* Re: Linux 5.1-rc2
From: James Morris @ 2019-03-25 19:08 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linus Torvalds, Linux List Kernel Mailing, linux-security-module,
Kees Cook, Tetsuo Handa
In-Reply-To: <2d4f3bfa-22c7-a18c-3902-fe1b6ac401f7@infradead.org>
On Sun, 24 Mar 2019, Randy Dunlap wrote:
> On 3/24/19 2:26 PM, Linus Torvalds wrote:
> > Well, we're a week away from the merge window close, and here's rc2.
> > Things look fairly normal, but honestly, rc2 is usually too early to
> > tell. People haven't necessarily had time to notice problems yet.
> > Which is just another way of saying "please test harder".
> >
> > Nothing particularly stands out. Yes, we had some fixes for the new
> > io_ring code for issues that were discussed when merging it. Other
> > than that, worth noting is that the bulk of the patches are for
> > tooling, not the core kernel. In fact, about two thirds of the patch
> > is just for the tools/ subdirectory, most of it due to some late perf
> > tool updates. The people involved promise they're done.
>
> Hmph. I'm still looking for the patch that restores the various
> CONFIG_DEFAULT_<security> kconfig options to be merged.
>
> https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
>
> since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.
AFAICT we don't have a finalized version of the patch yet.
Kees?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: Repost: Missing security_mmap_file() in remap_file_pages syscall
From: Kirill A. Shutemov @ 2019-03-25 17:47 UTC (permalink / raw)
To: TongZhang
Cc: LKML, linux-security-module, akpm, mhocko, dan.j.williams,
rientjes, aarcange, dave, kirill.shutemov, Stephen Smalley,
Shen Wenbo
In-Reply-To: <A6FCC3DA-C72C-4B59-A27E-E91F85949608@vt.edu>
On Mon, Mar 25, 2019 at 01:33:51PM -0400, TongZhang wrote:
> Dear Kernel Developers,
>
> We’d like to bring this up for a discussion again.
>
> Several months ago we posted an email discussing a case where remap_file_pages() has no security_mmap_file() check.
> At that time we were told that do_mmap_pgoff() will base the new VMA permission on the old one.
> But somehow we still think the check is needed, for the reason that the advisory could first do a
> mmap() which can pass SELinux check then remap using a completely different file or region of file,
> which could possibly pose a risk.
Could you elabarote on the risk you see? A bad scenario that could be
prevented with SELinux check would be helpful.
--
Kirill A. Shutemov
^ permalink raw reply
* Repost: Missing security_mmap_file() in remap_file_pages syscall
From: TongZhang @ 2019-03-25 17:33 UTC (permalink / raw)
To: LKML, linux-security-module
Cc: akpm, mhocko, dan.j.williams, rientjes, aarcange, dave,
kirill.shutemov, Stephen Smalley, Shen Wenbo
Dear Kernel Developers,
We’d like to bring this up for a discussion again.
Several months ago we posted an email discussing a case where remap_file_pages() has no security_mmap_file() check.
At that time we were told that do_mmap_pgoff() will base the new VMA permission on the old one.
But somehow we still think the check is needed, for the reason that the advisory could first do a
mmap() which can pass SELinux check then remap using a completely different file or region of file,
which could possibly pose a risk.
Thanks,
- Tong
The original post is pasted below:
8<—————————————————————————————
[1.] One line summary of the problem:
Possible missing security_mmap_file() in remap_file_pages
[2.] Full description of the problem/report:
We noticed remap_file_pages syscall uses do_mmap_pgoff without LSM check: security_mmap_file().
This system call passed user controllable parameters to do_mmap_pgoff().
We think that this LSM check should be added in order to be consistent with other cases,
for example:
in system call mmap_pgoff(), shmat(), they all have security_mmap_file() check before calling
do_mmap_pgoff().
[3.] Keywords: LSM check
[4.] Kernel information
[4.1] Kernel Version: 4.14.61
8<—————————————————————————————
^ permalink raw reply
* Re: [PATCH] KEYS: trusted: defer execution of TPM-specific code until key instantiate
From: Jarkko Sakkinen @ 2019-03-25 14:56 UTC (permalink / raw)
To: Roberto Sassu
Cc: dhowells, zohar, dan.j.williams, linux-integrity, keyrings,
linux-security-module, linux-kernel, linux-nvdimm, david.safford,
jejb, silviu.vlasceanu, stable
In-Reply-To: <20190322180139.18856-1-roberto.sassu@huawei.com>
On Fri, Mar 22, 2019 at 07:01:39PM +0100, Roberto Sassu wrote:
> Commit 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure from
> tpm_default_chip()") changed the tpm_chip argument of every TPM function
> from NULL to a pointer that is retrieved at module initialization time.
>
> Unlike before this patch, the trusted module cannot be loaded if no TPM is
> available. Unfortunately, this causes a dependency problem because the
> encrypted key type requires the 'key_type_trusted' symbol when
> CONFIG_TRUSTED_KEYS is defined.
>
> This patch fixes the issue by deferring the execution of TPM-specific code
> until a new trusted key is instantiated: init_tpm(), to obtain a tpm_chip
> pointer; init_digests(), introduced by commit 0b6cf6b97b7e ("tpm: pass an
> array of tpm_extend_digest structures to tpm_pcr_extend()"), to get random
> bytes from the TPM to lock a PCR.
>
> Cc: stable@vger.kernel.org
> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure from tpm_default_chip()")
> Reported-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
Definitive NAK for the release. Sorting out the dependency problem is
definitely out of scope for v5.1.
/Jarkko
^ permalink raw reply
* Re: [PATCH v19 17/27] x86/sgx: Add provisioning
From: Jarkko Sakkinen @ 2019-03-25 14:55 UTC (permalink / raw)
To: Andy Lutomirski
Cc: X86 ML, linux-sgx, Andrew Morton, Dave Hansen,
Christopherson, Sean J, nhorman, npmccallum, Ayoun, Serge,
Katz-zamir, Shay, Huang, Haitao, Andy Shevchenko, Thomas Gleixner,
Svahn, Kai, Borislav Petkov, Josh Triplett, Huang, Kai,
David Rientjes, James Morris, Serge E . Hallyn, LSM List
In-Reply-To: <CALCETrW=Fr8EdVq+5FLbmdL__i82FC0ONHd=hBXjxpLcsv9M0Q@mail.gmail.com>
On Fri, Mar 22, 2019 at 11:20:30AM -0700, Andy Lutomirski wrote:
> On Fri, Mar 22, 2019 at 4:43 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Fri, Mar 22, 2019 at 01:29:38PM +0200, Jarkko Sakkinen wrote:
> > > On Thu, Mar 21, 2019 at 09:50:41AM -0700, Andy Lutomirski wrote:
> > > > On Sun, Mar 17, 2019 at 2:18 PM Jarkko Sakkinen
> > > > <jarkko.sakkinen@linux.intel.com> wrote:
> > > > >
> > > > > In order to provide a mechanism for devilering provisoning rights:
> > > > >
> > > > > 1. Add a new file to the securityfs file called sgx/provision that works
> > > > > as a token for allowing an enclave to have the provisioning privileges.
> > > > > 2. Add a new ioctl called SGX_IOC_ENCLAVE_SET_ATTRIBUTE that accepts the
> > > > > following data structure:
> > > > >
> > > > > struct sgx_enclave_set_attribute {
> > > > > __u64 addr;
> > > > > __u64 token_fd;
> > > > > };
> > > >
> > > > Here's a potential issue:
> > > >
> > > > For container use, is it reasonable for a container manager to
> > > > bind-mount a file into securityfs? Or would something in /dev make
> > > > this easier?
> > >
> > > I guess that is a valid point given that the securityfs contains the LSM
> > > (e.g. SELinux or AppArmor) policy. So yeah, I think your are right what
> > > you say.
> > >
> > > I propose that we create /dev/sgx/enclave to act as the enclave manager
> > > and /dev/sgx/provision for provisioning. Is this sustainable for you?
> >
> > Hmm.. on 2nd thought the LSM policy or even DAC policy would restrict
> > that the container manager can only access specific files inside
> > securityfs. With this conclusion I still think it is probably the best
> > place for seurity policy like things even for SGX. It is meant for that
> > anyway.
> >
>
> LSM or DAC policy can certainly *restrict* it, but I suspect that most
> container runtimes don't mount securityfs at all. OTOH, the runtime
> definitely needs to have a way to pass /dev/sgx/enclave (or whatever
> it's called) through, so using another device node will definitely
> work.
OK, I can cope with this argument. I go with the device names above for
v20.
/Jarkko
^ permalink raw reply
* [PATCH] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
From: Jarkko Sakkinen @ 2019-03-25 14:47 UTC (permalink / raw)
To: linux-integrity
Cc: linux-security-module, Jarkko Sakkinen, Dan Williams, stable,
James Bottomley, Mimi Zohar, David Howells, James Morris,
Serge E. Hallyn, open list:KEYS-TRUSTED, open list
Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
key type callbacks and exported functions to fail when a TPM is not
available.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: stable@vger.kernel.org
Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
security/keys/trusted.c | 46 +++++++++++++++++++++++++++++++++++------
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/security/keys/trusted.c b/security/keys/trusted.c
index ecec672d3a77..13fb1068e371 100644
--- a/security/keys/trusted.c
+++ b/security/keys/trusted.c
@@ -135,6 +135,9 @@ int TSS_authhmac(unsigned char *digest, const unsigned char *key,
int ret;
va_list argp;
+ if (!chip)
+ return -ENODEV;
+
sdesc = init_sdesc(hashalg);
if (IS_ERR(sdesc)) {
pr_info("trusted_key: can't alloc %s\n", hash_alg);
@@ -196,6 +199,9 @@ int TSS_checkhmac1(unsigned char *buffer,
va_list argp;
int ret;
+ if (!chip)
+ return -ENODEV;
+
bufsize = LOAD32(buffer, TPM_SIZE_OFFSET);
tag = LOAD16(buffer, 0);
ordinal = command;
@@ -363,6 +369,9 @@ int trusted_tpm_send(unsigned char *cmd, size_t buflen)
{
int rc;
+ if (!chip)
+ return -ENODEV;
+
dump_tpm_buf(cmd);
rc = tpm_send(chip, cmd, buflen);
dump_tpm_buf(cmd);
@@ -429,6 +438,9 @@ int oiap(struct tpm_buf *tb, uint32_t *handle, unsigned char *nonce)
{
int ret;
+ if (!chip)
+ return -ENODEV;
+
INIT_BUF(tb);
store16(tb, TPM_TAG_RQU_COMMAND);
store32(tb, TPM_OIAP_SIZE);
@@ -967,6 +979,9 @@ static int trusted_instantiate(struct key *key,
size_t key_len;
int tpm2;
+ if (!chip)
+ return -ENODEV;
+
tpm2 = tpm_is_tpm2(chip);
if (tpm2 < 0)
return tpm2;
@@ -1050,6 +1065,9 @@ static void trusted_rcu_free(struct rcu_head *rcu)
{
struct trusted_key_payload *p;
+ if (!chip)
+ return;
+
p = container_of(rcu, struct trusted_key_payload, rcu);
kzfree(p);
}
@@ -1066,6 +1084,9 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
char *datablob;
int ret = 0;
+ if (!chip)
+ return -ENODEV;
+
if (key_is_negative(key))
return -ENOKEY;
p = key->payload.data[0];
@@ -1144,6 +1165,9 @@ static long trusted_read(const struct key *key, char __user *buffer,
char *bufp;
int i;
+ if (!chip)
+ return -ENODEV;
+
p = dereference_key_locked(key);
if (!p)
return -EINVAL;
@@ -1170,6 +1194,9 @@ static long trusted_read(const struct key *key, char __user *buffer,
*/
static void trusted_destroy(struct key *key)
{
+ if (!chip)
+ return;
+
kzfree(key->payload.data[0]);
}
@@ -1245,9 +1272,13 @@ static int __init init_trusted(void)
{
int ret;
+ /* encrypted_keys.ko depends on successful load of this module even if
+ * TPM is not used.
+ */
chip = tpm_default_chip();
if (!chip)
- return -ENOENT;
+ return 0;
+
ret = init_digests();
if (ret < 0)
goto err_put;
@@ -1263,16 +1294,19 @@ static int __init init_trusted(void)
err_free:
kfree(digests);
err_put:
- put_device(&chip->dev);
+ if (chip)
+ put_device(&chip->dev);
return ret;
}
static void __exit cleanup_trusted(void)
{
- put_device(&chip->dev);
- kfree(digests);
- trusted_shash_release();
- unregister_key_type(&key_type_trusted);
+ if (chip) {
+ put_device(&chip->dev);
+ kfree(digests);
+ trusted_shash_release();
+ unregister_key_type(&key_type_trusted);
+ }
}
late_initcall(init_trusted);
--
2.19.1
^ permalink raw reply related
* Re: [PATCH] LSM: lsm_hooks.h - fix missing colon in docstring
From: Paul Moore @ 2019-03-25 14:08 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: selinux, Stephen Smalley, linux-security-module, kbuild-all,
kbuild test robot
In-Reply-To: <20190325080535.19475-1-omosnace@redhat.com>
On Mon, Mar 25, 2019 at 4:05 AM Ondrej Mosnacek <omosnace@redhat.com> wrote:
> Apparently without it it is incorrect syntax and causes a warning about
> undocumented struct field.
>
> Fixes: b230d5aba2d1 ("LSM: add new hook for kernfs node initialization")
> Reported-by: kbuild test robot <lkp@intel.com>
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
> ---
> include/linux/lsm_hooks.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
If it makes you feel any better, I didn't realize the colon was that
important either. Thanks for the fix, merged into selinux/next.
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 0dd5bda719e6..b987dc282d63 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -447,7 +447,7 @@
> *
> * Security hooks for kernfs node operations
> *
> - * @kernfs_init_security
> + * @kernfs_init_security:
> * Initialize the security context of a newly created kernfs node based
> * on its own and its parent's attributes.
> *
> --
> 2.20.1
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: INFO: task hung in process_measurement
From: Tomi Valkeinen @ 2019-03-25 11:57 UTC (permalink / raw)
To: syzbot, airlied, dmitry.kasatkin, dri-devel, james.l.morris,
jmorris, jsarha, linux-ima-devel, linux-ima-user, linux-integrity,
linux-kernel, linux-security-module, serge, syzkaller-bugs, zohar
In-Reply-To: <000000000000f8654a0584bd7d5d@google.com>
On 23/03/2019 08:58, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 8fe5616b20e5742bb5fee0e77dffe2fc76ac92a0
> Author: Jyri Sarha <jsarha@ti.com>
> Date: Tue Jun 14 08:43:30 2016 +0000
>
> drm/tilcdc: Restore old dpms state in pm_resume()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10daff1b200000
> start commit: 291d0e5d Merge tag 'for-linus-20180929' of
> git://git.kerne..
> git tree: upstream
> final crash: https://syzkaller.appspot.com/x/report.txt?x=12daff1b200000
> console output: https://syzkaller.appspot.com/x/log.txt?x=14daff1b200000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a8212f992609a887
> dashboard link:
> https://syzkaller.appspot.com/bug?extid=cdc562bc26a2b2b0a94f
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=140e285e400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1237fe81400000
>
> Reported-by: syzbot+cdc562bc26a2b2b0a94f@syzkaller.appspotmail.com
> Fixes: 8fe5616b20e5 ("drm/tilcdc: Restore old dpms state in pm_resume()")
>
> For information about bisection process see:
> https://goo.gl/tpsmEJ#bisection
I don't think the patch from Jyri is related to the crash here.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH] LSM: lsm_hooks.h - fix missing colon in docstring
From: Ondrej Mosnacek @ 2019-03-25 8:05 UTC (permalink / raw)
To: selinux, Paul Moore
Cc: Stephen Smalley, linux-security-module, kbuild-all,
Ondrej Mosnacek, kbuild test robot
In-Reply-To: <201903211834.Qtb0LJ32%lkp@intel.com>
Apparently without it it is incorrect syntax and causes a warning about
undocumented struct field.
Fixes: b230d5aba2d1 ("LSM: add new hook for kernfs node initialization")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
---
include/linux/lsm_hooks.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 0dd5bda719e6..b987dc282d63 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -447,7 +447,7 @@
*
* Security hooks for kernfs node operations
*
- * @kernfs_init_security
+ * @kernfs_init_security:
* Initialize the security context of a newly created kernfs node based
* on its own and its parent's attributes.
*
--
2.20.1
^ permalink raw reply related
* Re: Linux 5.1-rc2
From: Randy Dunlap @ 2019-03-25 2:31 UTC (permalink / raw)
To: Linus Torvalds, Linux List Kernel Mailing
Cc: linux-security-module, Kees Cook, Tetsuo Handa, James Morris
In-Reply-To: <CAHk-=wgg_PRWs3a6u2gnFLQjhxOJcrFkqqWVnLw60eQAwD-DNw@mail.gmail.com>
On 3/24/19 2:26 PM, Linus Torvalds wrote:
> Well, we're a week away from the merge window close, and here's rc2.
> Things look fairly normal, but honestly, rc2 is usually too early to
> tell. People haven't necessarily had time to notice problems yet.
> Which is just another way of saying "please test harder".
>
> Nothing particularly stands out. Yes, we had some fixes for the new
> io_ring code for issues that were discussed when merging it. Other
> than that, worth noting is that the bulk of the patches are for
> tooling, not the core kernel. In fact, about two thirds of the patch
> is just for the tools/ subdirectory, most of it due to some late perf
> tool updates. The people involved promise they're done.
Hmph. I'm still looking for the patch that restores the various
CONFIG_DEFAULT_<security> kconfig options to be merged.
https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.
--
~Randy
^ permalink raw reply
* [PATCH 2/2 v2] efi: print appropriate status message when loading certificates
From: Lee, Chun-Yi @ 2019-03-24 0:26 UTC (permalink / raw)
To: Ard Biesheuvel, James Morris, Serge E . Hallyn, David Howells,
Josh Boyer, Nayna Jain, Mimi Zohar
Cc: linux-efi, linux-security-module, linux-kernel, Lee, Chun-Yi
In-Reply-To: <20190324002621.3551-1-jlee@suse.com>
When loading certificates list from UEFI variable, the original error
message direct shows the efi status code from UEFI firmware. It looks
ugly:
[ 2.335031] Couldn't get size: 0x800000000000000e
[ 2.335032] Couldn't get UEFI MokListRT
[ 2.339985] Couldn't get size: 0x800000000000000e
[ 2.339987] Couldn't get UEFI dbx list
So, this patch shows the status string instead of status code.
On the other hand, the "Couldn't get UEFI" message doesn't need
to be exposed when db/dbx/mok variable do not exist. So, this
patch set the message level to debug.
v2.
Setting the MODSIGN messagse level to debug.
Link: https://forums.opensuse.org/showthread.php/535324-MODSIGN-Couldn-t-get-UEFI-db-list?p=2897516#post2897516
Cc: James Morris <jmorris@namei.org>
Cc: Serge E. Hallyn" <serge@hallyn.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: "Lee, Chun-Yi" <jlee@suse.com>
---
security/integrity/platform_certs/load_uefi.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 81b19c52832b..e65244b31f04 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -48,7 +48,9 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
status = efi.get_variable(name, guid, NULL, &lsize, &tmpdb);
if (status != EFI_BUFFER_TOO_SMALL) {
- pr_err("Couldn't get size: 0x%lx\n", status);
+ if (status != EFI_NOT_FOUND)
+ pr_err("Couldn't get size: %s\n",
+ efi_status_to_str(status));
return NULL;
}
@@ -59,7 +61,8 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
status = efi.get_variable(name, guid, NULL, &lsize, db);
if (status != EFI_SUCCESS) {
kfree(db);
- pr_err("Error reading db var: 0x%lx\n", status);
+ pr_err("Error reading db var: %s\n",
+ efi_status_to_str(status));
return NULL;
}
@@ -155,7 +158,7 @@ static int __init load_uefi_certs(void)
if (!uefi_check_ignore_db()) {
db = get_cert_list(L"db", &secure_var, &dbsize);
if (!db) {
- pr_err("MODSIGN: Couldn't get UEFI db list\n");
+ pr_debug("MODSIGN: Couldn't get UEFI db list\n");
} else {
rc = parse_efi_signature_list("UEFI:db",
db, dbsize, get_handler_for_db);
@@ -168,7 +171,7 @@ static int __init load_uefi_certs(void)
mok = get_cert_list(L"MokListRT", &mok_var, &moksize);
if (!mok) {
- pr_info("Couldn't get UEFI MokListRT\n");
+ pr_debug("Couldn't get UEFI MokListRT\n");
} else {
rc = parse_efi_signature_list("UEFI:MokListRT",
mok, moksize, get_handler_for_db);
@@ -179,7 +182,7 @@ static int __init load_uefi_certs(void)
dbx = get_cert_list(L"dbx", &secure_var, &dbxsize);
if (!dbx) {
- pr_info("Couldn't get UEFI dbx list\n");
+ pr_debug("Couldn't get UEFI dbx list\n");
} else {
rc = parse_efi_signature_list("UEFI:dbx",
dbx, dbxsize,
--
2.16.4
^ permalink raw reply related
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