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; /* -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
