[PATCH 0/2] Secure Boot: More controversial changes

[PATCH 0/2] Secure Boot: More controversial changes

[Matthew Garrett]

These patches break functionality that people rely on without providing
any functional equivalent, so I'm not suggesting that they be merged
as-is. kexec allows trivial circumvention of the trust model (it's
trivially equivalent to permitting module loading, for instance) and
hibernation allows similar attacks (disable swap, write a pre-formed resume
image to swap, reboot). The hibernation patch also shows up a different
issue - some userspace drops all capabilities, resulting in things that
userspace expects to work no longer working. This seems like an
unsurprising result, but breaking userspace is bad and so it'd be nice to
figure out if there's another way to handle this.

[PATCH 1/2] kexec: Disable in a secure boot environment

[Matthew Garrett]

kexec could be used as a vector for a malicious user to use a signed kernel
to circumvent the secure boot trust model. In the long run we'll want to
support signed kexec payloads, but for the moment we should just disable
loading entirely in that situation.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
---
 kernel/kexec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/kexec.c b/kernel/kexec.c
index 5e4bd78..dd464e0 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -943,7 +943,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
 	int result;
 
 	/* We only trust the superuser with rebooting the system. */
-	if (!capable(CAP_SYS_BOOT))
+	if (!capable(CAP_SYS_BOOT) || !capable(CAP_COMPROMISE_KERNEL))
 		return -EPERM;
 
 	/*
-- 
1.8.0.2

[PATCH 2/2] hibernate: Disable in a Secure Boot environment

[Matthew Garrett]

From: Josh Boyer <jwboyer@redhat.com>

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the secure boot trust model,
so until we can work with signed hibernate images we disable it in
a Secure Boot environment.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
---
 kernel/power/hibernate.c | 14 +++++++++++++-
 kernel/power/main.c      |  7 ++++++-
 kernel/power/user.c      |  3 +++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index b26f5f1..14b6344 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -632,6 +632,10 @@ int hibernate(void)
 {
 	int error;
 
+	if (!capable(CAP_COMPROMISE_KERNEL)) {
+		return -EPERM;
+	}
+
 	lock_system_sleep();
 	/* The snapshot device should not be opened while we're running */
 	if (!atomic_add_unless(&snapshot_device_available, -1, 0)) {
@@ -723,7 +727,7 @@ static int software_resume(void)
 	/*
 	 * If the user said "noresume".. bail out early.
 	 */
-	if (noresume)
+	if (noresume || !capable(CAP_COMPROMISE_KERNEL))
 		return 0;
 
 	/*
@@ -889,6 +893,11 @@ static ssize_t disk_show(struct kobject *kobj, struct kobj_attribute *attr,
 	int i;
 	char *start = buf;
 
+	if (!cap_capable(CAP_COMPROMISE_KERNEL)) {
+		buf += sprintf(buf, "[%s]\n", "disabled");
+		return buf-start;
+	}
+
 	for (i = HIBERNATION_FIRST; i <= HIBERNATION_MAX; i++) {
 		if (!hibernation_modes[i])
 			continue;
@@ -923,6 +932,9 @@ static ssize_t disk_store(struct kobject *kobj, struct kobj_attribute *attr,
 	char *p;
 	int mode = HIBERNATION_INVALID;
 
+	if (!capable(CAP_COMPROMISE_KERNEL))
+		return -EPERM;
+
 	p = memchr(buf, '\n', n);
 	len = p ? p - buf : n;
 
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..42f5d94 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -15,6 +15,7 @@
 #include <linux/workqueue.h>
 #include <linux/debugfs.h>
 #include <linux/seq_file.h>
+#include <linux/efi.h>
 
 #include "power.h"
 
@@ -301,7 +302,11 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 	}
 #endif
 #ifdef CONFIG_HIBERNATION
-	s += sprintf(s, "%s\n", "disk");
+	if (capable(CAP_COMPROMISE_KERNEL) {
+		s += sprintf(s, "%s\n", "disk");
+	} else {
+		s += sprintf(s, "\n");
+	}
 #else
 	if (s != buf)
 		/* convert the last space to a newline */
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 4ed81e7..b11a0f4 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -48,6 +48,9 @@ static int snapshot_open(struct inode *inode, struct file *filp)
 	struct snapshot_data *data;
 	int error;
 
+	if (!capable(CAP_COMPROMISE_KERNEL))
+		return -EPERM;
+
 	lock_system_sleep();
 
 	if (!atomic_add_unless(&snapshot_device_available, -1, 0)) {
-- 
1.8.0.2

Re: [PATCH 0/2] Secure Boot: More controversial changes

[H. Peter Anvin]

On 01/28/2013 08:47 AM, Matthew Garrett wrote:
> These patches break functionality that people rely on without providing
> any functional equivalent, so I'm not suggesting that they be merged
> as-is. kexec allows trivial circumvention of the trust model (it's
> trivially equivalent to permitting module loading, for instance) and
> hibernation allows similar attacks (disable swap, write a pre-formed resume
> image to swap, reboot). The hibernation patch also shows up a different
> issue - some userspace drops all capabilities, resulting in things that
> userspace expects to work no longer working. This seems like an
> unsurprising result, but breaking userspace is bad and so it'd be nice to
> figure out if there's another way to handle this.

These at the very least need some kind of CONFIG_WEAK_SECURE_BOOT option 
or something like that.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH 0/2] Secure Boot: More controversial changes

[H. Peter Anvin]

On 01/28/2013 08:47 AM, Matthew Garrett wrote:
> These patches break functionality that people rely on without providing
> any functional equivalent, so I'm not suggesting that they be merged
> as-is. kexec allows trivial circumvention of the trust model (it's
> trivially equivalent to permitting module loading, for instance) and
> hibernation allows similar attacks (disable swap, write a pre-formed resume
> image to swap, reboot). The hibernation patch also shows up a different
> issue - some userspace drops all capabilities, resulting in things that
> userspace expects to work no longer working. This seems like an
> unsurprising result, but breaking userspace is bad and so it'd be nice to
> figure out if there's another way to handle this.

These at the very least need some kind of CONFIG_WEAK_SECURE_BOOT option 
or something like that.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH 0/2] Secure Boot: More controversial changes

[Matthew Garrett]

On Mon, Jan 28, 2013 at 06:05:56PM -0800, H. Peter Anvin wrote:
> These at the very least need some kind of CONFIG_WEAK_SECURE_BOOT
> option or something like that.

Given Eric's views on the kexec patch (and given that there's no point 
in the hibernate one if kexec's available...), I'm not planning on 
pushing these until there's a plausible story for limiting kexec to 
signed images.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: [PATCH 0/2] Secure Boot: More controversial changes

[Matthew Garrett]

On Mon, Jan 28, 2013 at 06:05:56PM -0800, H. Peter Anvin wrote:
> These at the very least need some kind of CONFIG_WEAK_SECURE_BOOT
> option or something like that.

Given Eric's views on the kexec patch (and given that there's no point 
in the hibernate one if kexec's available...), I'm not planning on 
pushing these until there's a plausible story for limiting kexec to 
signed images.

-- 
Matthew Garrett | mjg59@srcf.ucam.org