From: Matthew Garrett
Date: Mon Mar 18 2013 - 17:38:34 EST

kexec can easily be used to modify the security policy of a running kernel.
CONFIG_KEXEC_JUMP makes it trivial for an attacker to simply jump to another
kernel, modify the security policy of the previous kernel and then switch
back, but it's still merely a matter of difficulty. Long term we'll want
an interface for ensuring that kexec is able to launch signed code, but we
should default to safe behaviour for now.

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

diff --git a/kernel/kexec.c b/kernel/kexec.c
index bddd3d7..cbdb930 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -946,7 +946,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;


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/