* [PATCH 16/24] ACPI: Limit access to custom_method when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-acpi at vger.kernel.org
---
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 c68e72414a67..e4d721c330c0 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())
+ return -EPERM;
+
if (!(*ppos)) {
/* parse the table header to get the table length */
if (count <= sizeof(struct acpi_table_header))
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info@ http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 13/24] x86: Lock down IO port access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: matthew.garrett, linux-efi, gnomes, gregkh, x86, dhowells,
linux-security-module, keyrings
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org
---
arch/x86/kernel/ioport.c | 4 ++--
drivers/char/mem.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 9c3cf0944bce..4a613fed94b6 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -30,7 +30,7 @@ asmlinkage long sys_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()))
return -EPERM;
/*
@@ -120,7 +120,7 @@ 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())
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f8144049bda3..9afebb60550f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -741,6 +741,8 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
static int open_port(struct inode *inode, struct file *filp)
{
+ if (kernel_is_locked_down())
+ return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
^ permalink raw reply related
* [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if the
kernel is locked down.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: acpi4asus-user at lists.sourceforge.net
cc: platform-driver-x86 at vger.kernel.org
---
drivers/platform/x86/asus-wmi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 8fe5890bf539..feef25076813 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1900,6 +1900,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
if (err < 0)
@@ -1916,6 +1919,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
&retval);
@@ -1940,6 +1946,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
1, asus->debug.method_id,
&input, &output);
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: matthew.garrett, linux-efi, gnomes, gregkh, acpi4asus-user,
platform-driver-x86, dhowells, linux-security-module, keyrings
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions. Prevent that if the
kernel is locked down.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
---
drivers/platform/x86/asus-wmi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 8fe5890bf539..feef25076813 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -1900,6 +1900,9 @@ static int show_dsts(struct seq_file *m, void *data)
int err;
u32 retval = -1;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
err = asus_wmi_get_devstate(asus, asus->debug.dev_id, &retval);
if (err < 0)
@@ -1916,6 +1919,9 @@ static int show_devs(struct seq_file *m, void *data)
int err;
u32 retval = -1;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
err = asus_wmi_set_devstate(asus->debug.dev_id, asus->debug.ctrl_param,
&retval);
@@ -1940,6 +1946,9 @@ static int show_call(struct seq_file *m, void *data)
union acpi_object *obj;
acpi_status status;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
status = wmi_evaluate_method(ASUS_WMI_MGMT_GUID,
1, asus->debug.method_id,
&input, &output);
^ permalink raw reply related
* [PATCH 14/24] x86: Restrict MSR access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
cc: x86 at kernel.org
---
arch/x86/kernel/msr.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index ef688804f80d..fbcce028e502 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,9 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
int err = 0;
ssize_t bytes = 0;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
@@ -131,6 +134,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)
err = -EBADF;
break;
}
+ if (kernel_is_locked_down()) {
+ err = -EPERM;
+ break;
+ }
if (copy_from_user(®s, uregs, sizeof regs)) {
err = -EFAULT;
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 14/24] x86: Restrict MSR access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: matthew.garrett, linux-efi, Kees Cook, gnomes, gregkh, x86,
dhowells, linux-security-module, keyrings
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode. Based on a
patch by Kees Cook.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
cc: x86@kernel.org
---
arch/x86/kernel/msr.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
index ef688804f80d..fbcce028e502 100644
--- a/arch/x86/kernel/msr.c
+++ b/arch/x86/kernel/msr.c
@@ -84,6 +84,9 @@ static ssize_t msr_write(struct file *file, const char __user *buf,
int err = 0;
ssize_t bytes = 0;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (count % 8)
return -EINVAL; /* Invalid chunk size */
@@ -131,6 +134,10 @@ static long msr_ioctl(struct file *file, unsigned int ioc, unsigned long arg)
err = -EBADF;
break;
}
+ if (kernel_is_locked_down()) {
+ err = -EPERM;
+ break;
+ }
if (copy_from_user(®s, uregs, sizeof regs)) {
err = -EFAULT;
break;
^ permalink raw reply related
* Re: uid_attrs (was Re: [PATCH 04/11] multipathd: add need_do_map to indicate whether need calling domap() in ev_add_path())
From: Martin Wilck @ 2017-04-05 20:16 UTC (permalink / raw)
To: Benjamin Marzinski
Cc: tang.junhui, tang.wenjun3, zhang.kai16, dm-devel, bart.vanassche
In-Reply-To: <20170405184523.GF19236@octiron.msp.redhat.com>
On Wed, 2017-04-05 at 13:45 -0500, Benjamin Marzinski wrote:
> On Wed, Apr 05, 2017 at 03:26:06PM +0200, Martin Wilck wrote:
> > >From the end user point of view, "uid_attrs" seems to simply
> duplicate
> > the functionality of "uid_attribute", just in more awkward syntax,
> and
> > with higher priority. As a side effect, it enables uevent merging,
> > which is documented in the man page but unexpected from the name of
> the
> > option.
>
> It should probably do a better job of masking "uid_attribute". The
> places in the code that currently use "uid_attribute" should all
> switch
> to using "uid_attrs" if it is set and applies to the device.
> If they
> don't, we could be in a situation where "uid_attrs" and
> "uid_attribute"
> are set to give different wwids, and a path's wwid could change based
> on
> whether or not ID_SERIAL was filled in when multipath got
I'm not quite sure what you mean. The way it's currently implemented is
in select_getuid(), pp->uid_attribute will be set from uid_attrs if it
exists and matches the device name, and will henceforth be used
everywhere where uid_attribute for this path is referenced.
I don't see how this could lead to inconsistent settings.
Even for RBD devices, uid_attrs would take precedence if users could
uid_attrs="rbd:SOME_VARIABLE". (Btw, why do we hardcode the WWID
generation for RBD rather than writing rbd udev rules and using the
udev attributes created by them)?
> > Anyway, I wonder if it would still be possible to change this at
> > this
> > point in time (i.e. after "uid_attrs" was merged).
>
> It's always possible to change things. As far as Red Hat goes, we
> haven't pulled in these changes yet, but I'm planning on rebasing
> Fedora
> to upstream shortly.
We're planning the same for openSUSE Factory. Currently we've left out
Tang's patch, but the plan is to pull in upstream cleanly.
> So, it won't cause me any problems if uid_attrs
> goes away as long as it does so in the near future. I have no idea if
> other distributions have pulled this in. If so, then uid_attrs
> probably
> needs to remain accepted as a valid option by multipath. But since
> all
> correct configurations have it give the same answers as
> uid_attribute,
> we could probably just make the option do nothing.
>
> Of course, all this depends on your solution actually being enough
> better than Tang's to justify pulling his version out.
Point taken :-) I don't have patches at this time. However, let me make
a suggestion. Does "uid_attrs" really have to be user-configurable? IMO
configuring this is asked too much from 99% of users. I'd suggest to
hard-code the value of uid_attrs and use a boolean configuration option
in the defaults section ("auto_uid_attribute", say) which would control
whether WWID attributes should be configured "the uid_attrs way" or the
"traditional way" (traditional being the fallback if uid_attrs didn't
match, like now). Hard-coding this would have the advantage that we
wouldn't be bound to the "sd:..." syntax. Rather, we could explore more
intelligent ways to autodetect the uid_attribute depending on path
properties which are known early on.
Uevent merging could be controlled by a separate config option which
would depend on the "auto_uid_attribute" option. This would mainly be
done for clarity.
Regards
Martin
--
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply
* [PATCH 13/24] x86: Lock down IO port access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
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 <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86 at kernel.org
---
arch/x86/kernel/ioport.c | 4 ++--
drivers/char/mem.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 9c3cf0944bce..4a613fed94b6 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -30,7 +30,7 @@ asmlinkage long sys_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()))
return -EPERM;
/*
@@ -120,7 +120,7 @@ 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())
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f8144049bda3..9afebb60550f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -741,6 +741,8 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
static int open_port(struct inode *inode, struct file *filp)
{
+ if (kernel_is_locked_down())
+ return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 13/24] x86: Lock down IO port access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
x86-DgEjT+Ai2ygdnm+yROfE0A, dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
keyrings-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <149142326734.5101.4596394505987813763.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
From: Matthew Garrett <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.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 <matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
cc: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
---
arch/x86/kernel/ioport.c | 4 ++--
drivers/char/mem.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index 9c3cf0944bce..4a613fed94b6 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -30,7 +30,7 @@ asmlinkage long sys_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()))
return -EPERM;
/*
@@ -120,7 +120,7 @@ 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())
return -EPERM;
}
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f8144049bda3..9afebb60550f 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -741,6 +741,8 @@ static loff_t memory_lseek(struct file *file, loff_t offset, int orig)
static int open_port(struct inode *inode, struct file *filp)
{
+ if (kernel_is_locked_down())
+ return -EPERM;
return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
}
^ permalink raw reply related
* Jewel 10.2.7 QE status
From: Yuri Weinstein @ 2017-04-05 20:16 UTC (permalink / raw)
To: Development, Ceph
Detailed summary of the QE Validation can be found here
http://tracker.ceph.com/issues/19055#note-13
The following suites were in scope of this point release validation:
rados (subset 35/50 227 jobceph-ansibles)
rbd
rgw
fs
krbd
kcephfs
knfs
rest
hadoop - EXCLUDED
samba - EXCLUDED
ceph-deploy
ceph-disk
upgrade/client-upgrade
upgrade/hammer-x (jewel)
upgrade/jewel-x/point-to-point-x
powercycle
ceph-ansible
(please let me know if any suites are missing from this ^ list)
=====================
Outstanding issues
rados - two jobs failed, need Josh's approval
krbd - seems similar to previous release, need Ilya's approval
upgrade/client-upgrade
and
upgrade/hammer-x (jewel) - suspect
http://tracker.ceph.com/issues/19429, need Sage/Josh approve
Thx
YuriW
^ permalink raw reply
* [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pci at vger.kernel.org
---
drivers/pci/pci-sysfs.c | 9 +++++++++
drivers/pci/proc.c | 8 +++++++-
drivers/pci/syscall.c | 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 25d010d449a3..f70b3668036f 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -727,6 +727,9 @@ static ssize_t pci_write_config(struct file *filp, struct kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1018,6 +1021,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
resource_size_t start, end;
int i;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
for (i = 0; i < PCI_ROM_RESOURCE; i++)
if (res == &pdev->resource[i])
break;
@@ -1117,6 +1123,9 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
+ if (kernel_is_locked_down())
+ return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index f82710a8694d..139d6f09ae7b 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -116,6 +116,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,
int size = dev->cfg_size;
int cnt;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -195,6 +198,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd,
#endif /* HAVE_PCI_MMAP */
int ret = 0;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -233,7 +239,7 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine;
- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || kernel_is_locked_down())
return -EPERM;
/* Make sure the caller is mapping a real resource for this device */
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index 9bf993e1f71e..c09524738ceb 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned long, dfn,
u32 dword;
int err = 0;
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN) || kernel_is_locked_down())
return -EPERM;
dev = pci_get_bus_and_slot(bus, dfn);
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 12/24] PCI: Lock down BAR access when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: matthew.garrett, linux-efi, gnomes, linux-pci, dhowells,
linux-security-module, keyrings, gregkh
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pci@vger.kernel.org
---
drivers/pci/pci-sysfs.c | 9 +++++++++
drivers/pci/proc.c | 8 +++++++-
drivers/pci/syscall.c | 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 25d010d449a3..f70b3668036f 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -727,6 +727,9 @@ static ssize_t pci_write_config(struct file *filp, struct kobject *kobj,
loff_t init_off = off;
u8 *data = (u8 *) buf;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -1018,6 +1021,9 @@ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
resource_size_t start, end;
int i;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
for (i = 0; i < PCI_ROM_RESOURCE; i++)
if (res == &pdev->resource[i])
break;
@@ -1117,6 +1123,9 @@ static ssize_t pci_write_resource_io(struct file *filp, struct kobject *kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
+ if (kernel_is_locked_down())
+ return -EPERM;
+
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index f82710a8694d..139d6f09ae7b 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -116,6 +116,9 @@ static ssize_t proc_bus_pci_write(struct file *file, const char __user *buf,
int size = dev->cfg_size;
int cnt;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
if (pos >= size)
return 0;
if (nbytes >= size)
@@ -195,6 +198,9 @@ static long proc_bus_pci_ioctl(struct file *file, unsigned int cmd,
#endif /* HAVE_PCI_MMAP */
int ret = 0;
+ if (kernel_is_locked_down())
+ return -EPERM;
+
switch (cmd) {
case PCIIOC_CONTROLLER:
ret = pci_domain_nr(dev->bus);
@@ -233,7 +239,7 @@ static int proc_bus_pci_mmap(struct file *file, struct vm_area_struct *vma)
struct pci_filp_private *fpriv = file->private_data;
int i, ret, write_combine;
- if (!capable(CAP_SYS_RAWIO))
+ if (!capable(CAP_SYS_RAWIO) || kernel_is_locked_down())
return -EPERM;
/* Make sure the caller is mapping a real resource for this device */
diff --git a/drivers/pci/syscall.c b/drivers/pci/syscall.c
index 9bf993e1f71e..c09524738ceb 100644
--- a/drivers/pci/syscall.c
+++ b/drivers/pci/syscall.c
@@ -92,7 +92,7 @@ SYSCALL_DEFINE5(pciconfig_write, unsigned long, bus, unsigned long, dfn,
u32 dword;
int err = 0;
- if (!capable(CAP_SYS_ADMIN))
+ if (!capable(CAP_SYS_ADMIN) || kernel_is_locked_down())
return -EPERM;
dev = pci_get_bus_and_slot(bus, dfn);
^ permalink raw reply related
* [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: Matthew Garrett, linux-efi, gnomes, Chun-Yi Lee, gregkh, kexec,
dhowells, linux-security-module, keyrings, matthew.garrett
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Chun-Yi Lee <joeyli.kernel@gmail.com>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---
kernel/kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b118735fea9d..f6937eecd1eb 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -268,6 +268,12 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
+ /* Don't permit images to be loaded into trusted kernels if we're not
+ * going to verify the signature on them
+ */
+ if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
+ return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related
* [PATCH 11/24] uswsusp: Disable when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
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>
cc: linux-pm at vger.kernel.org
---
kernel/power/user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 22df9f7ff672..e4b926d329b7 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())
+ return -EPERM;
+
lock_system_sleep();
if (!atomic_add_unless(&snapshot_device_available, -1, 0)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 11/24] uswsusp: Disable when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: Matthew Garrett, linux-efi, gnomes, gregkh, linux-pm, dhowells,
linux-security-module, keyrings, matthew.garrett
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
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>
cc: linux-pm@vger.kernel.org
---
kernel/power/user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 22df9f7ff672..e4b926d329b7 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())
+ return -EPERM;
+
lock_system_sleep();
if (!atomic_add_unless(&snapshot_device_available, -1, 0)) {
^ permalink raw reply related
* [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, linux-efi, matthew.garrett, gregkh, kexec, dhowells,
linux-security-module, keyrings, Dave Young
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Dave Young <dyoung@redhat.com>
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---
arch/x86/kernel/kexec-bzimage64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index d0a814a9d96a..3551bcaa1eaf 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
+ params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = current_ei->efi_systab;
ei->efi_systab_hi = current_ei->efi_systab_hi;
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related
* [PATCH 10/24] hibernate: Disable when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pm at vger.kernel.org
---
kernel/power/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a8b978c35a6a..50cca5dcb62f 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
bool hibernation_available(void)
{
- return (nohibernate == 0);
+ return nohibernate == 0 && !kernel_is_locked_down();
}
/**
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 10/24] hibernate: Disable when the kernel is locked down
From: David Howells @ 2017-04-05 20:16 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, Josh Boyer, linux-pm, linux-efi, gregkh, dhowells,
linux-security-module, keyrings, matthew.garrett
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Josh Boyer <jwboyer@fedoraproject.org>
There is currently no way to verify the resume image when returning
from hibernate. This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pm@vger.kernel.org
---
kernel/power/hibernate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a8b978c35a6a..50cca5dcb62f 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops;
bool hibernation_available(void)
{
- return (nohibernate == 0);
+ return nohibernate == 0 && !kernel_is_locked_down();
}
/**
^ permalink raw reply related
* [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: matthew.garrett, linux-efi, gnomes, gregkh, kexec, dhowells,
linux-security-module, keyrings
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.
This does not affect kexec_file_load() which can check for a signature on the
image to be booted.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---
kernel/kexec.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..46de8e6b42f4 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -194,6 +194,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
return -EPERM;
/*
+ * kexec can be used to circumvent module loading restrictions, so
+ * prevent loading in that case
+ */
+ if (kernel_is_locked_down())
+ return -EPERM;
+
+ /*
* Verify we have a legal set of flags
* This leaves us room for future extensions.
*/
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related
* [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Chun-Yi Lee <joeyli.kernel@gmail.com>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
kernel/kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b118735fea9d..f6937eecd1eb 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -268,6 +268,12 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
+ /* Don't permit images to be loaded into trusted kernels if we're not
+ * going to verify the signature on them
+ */
+ if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
+ return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 09/24] kexec_file: Disable at runtime if securelevel has been set
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Matthew Garrett, linux-efi-u79uwXL29TY76Z2rM5mHXA,
gnomes-qBU/x9rampVanCEyBjwyrvXRex20P6io, Chun-Yi Lee,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
keyrings-u79uwXL29TY76Z2rM5mHXA,
matthew.garrett-05XSO3Yj/JvQT0dZR+AlfA
In-Reply-To: <149142326734.5101.4596394505987813763.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
From: Chun-Yi Lee <joeyli.kernel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
When KEXEC_VERIFY_SIG is not enabled, kernel should not loads image
through kexec_file systemcall if securelevel has been set.
This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778
Cc: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
Signed-off-by: Chun-Yi Lee <jlee-IBi9RG/b67k@public.gmane.org>
Signed-off-by: David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
cc: kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
---
kernel/kexec_file.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index b118735fea9d..f6937eecd1eb 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -268,6 +268,12 @@ SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
if (!capable(CAP_SYS_BOOT) || kexec_load_disabled)
return -EPERM;
+ /* Don't permit images to be loaded into trusted kernels if we're not
+ * going to verify the signature on them
+ */
+ if (!IS_ENABLED(CONFIG_KEXEC_VERIFY_SIG) && kernel_is_locked_down())
+ return -EPERM;
+
/* Make sure we have a legal set of flags */
if (flags != (flags & KEXEC_FILE_FLAGS))
return -EINVAL;
^ permalink raw reply related
* [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Dave Young <dyoung@redhat.com>
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
arch/x86/kernel/kexec-bzimage64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index d0a814a9d96a..3551bcaa1eaf 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
+ params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = current_ei->efi_systab;
ei->efi_systab_hi = current_ei->efi_systab_hi;
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 08/24] Copy secure_boot flag in boot params across kexec reboot
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, linux-efi, matthew.garrett, gregkh, kexec, dhowells,
linux-security-module, keyrings, Dave Young
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Dave Young <dyoung@redhat.com>
Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load. In this state, the system is missing the protections provided
by secure boot.
Adding a patch to fix this by retain the secure_boot flag in original
kernel.
secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub. Fixing this issue by copying secure_boot flag across kexec reboot.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec@lists.infradead.org
---
arch/x86/kernel/kexec-bzimage64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index d0a814a9d96a..3551bcaa1eaf 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -179,6 +179,7 @@ setup_efi_state(struct boot_params *params, unsigned long params_load_addr,
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
+ params->secure_boot = boot_params.secure_boot;
ei->efi_loader_signature = current_ei->efi_loader_signature;
ei->efi_systab = current_ei->efi_systab;
ei->efi_systab_hi = current_ei->efi_systab_hi;
^ permalink raw reply related
* [Buildroot] [PATCHv3 00/12] toolchain: improvements to copy_toolchain_sysroot and copy_toolchain_lib_root
From: Thomas De Schampheleire @ 2017-04-05 20:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20170405215445.2b734880@free-electrons.com>
On Apr 5, 2017 21:54, "Thomas Petazzoni" <
thomas.petazzoni@free-electrons.com> wrote:
Hello,
On Tue, 7 Feb 2017 22:56:37 +0100, Thomas De Schampheleire wrote:
> Thomas De Schampheleire (12):
> toolchain-external: reduce nesting in copy_toolchain_sysroot
> toolchain-external: fix broken handling of 'usr/lib/locale'
> toolchain-external: clarify rsync excludes in copy_toolchain_sysroot
> toolchain-external: handle ld.so fixups centrally
> toolchain helpers: introduce function relpath_prefix
> toolchain-external: cover multilib toolchains with lib/<variant>
> layout
> toolchain helpers: introduce simplify_symlink
> toolchain-external: simplify previously-broken symbolic links
> toolchain: copy_toolchain_lib_root: remove unused variable LIBDIR
> toolchain: copy_toolchain_lib_root: clarify logic
> toolchain: copy_toolchain_lib_root: clarify input parameter
> toolchain: copy_toolchain_lib_root: copy symlinks instead of
> recreating them
I've now applied the remainder of the series, patches 3 to 12. I still
find this quite complicated overall, but I couldn't find any other
solution and nobody else did, and the problem scope is complicated
anyway.
Let's see the feedback we get from users :)
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170405/c5f5ae17/attachment.html>
^ permalink raw reply
* [PATCH 07/24] kexec: Disable at runtime if the kernel is locked down
From: David Howells @ 2017-04-05 20:15 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <149142326734.5101.4596394505987813763.stgit@warthog.procyon.org.uk>
From: Matthew Garrett <matthew.garrett@nebula.com>
kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.
This does not affect kexec_file_load() which can check for a signature on the
image to be booted.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: kexec at lists.infradead.org
---
kernel/kexec.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 980936a90ee6..46de8e6b42f4 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -194,6 +194,13 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
return -EPERM;
/*
+ * kexec can be used to circumvent module loading restrictions, so
+ * prevent loading in that case
+ */
+ if (kernel_is_locked_down())
+ return -EPERM;
+
+ /*
* Verify we have a legal set of flags
* This leaves us room for future extensions.
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.