From patchwork Mon Mar 18 21:32:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Garrett X-Patchwork-Id: 228821 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1FCC12C00B0 for ; Tue, 19 Mar 2013 08:39:38 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933222Ab3CRVia (ORCPT ); Mon, 18 Mar 2013 17:38:30 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:36043 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933219Ab3CRVi2 (ORCPT ); Mon, 18 Mar 2013 17:38:28 -0400 Received: from [2001:470:1f07:1371:e0f4:3a1:9c35:d688] (helo=x230.mview.int.nebula.com) by cavan.codon.org.uk with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UHhfy-0006Ez-0O; Mon, 18 Mar 2013 21:33:02 +0000 From: Matthew Garrett To: linux-kernel@vger.kernel.org Cc: linux-security-module@vger.kernel.org, linux-efi@vger.kernel.org, kexec@lists.infradead.org, linux-pci@vger.kernel.org, Matthew Garrett Subject: [PATCH 12/12] kexec: Require CAP_SYS_COMPROMISE_KERNEL Date: Mon, 18 Mar 2013 17:32:33 -0400 Message-Id: <1363642353-30749-12-git-send-email-matthew.garrett@nebula.com> X-Mailer: git-send-email 1.8.1.2 In-Reply-To: <1363642353-30749-1-git-send-email-matthew.garrett@nebula.com> References: <1363642353-30749-1-git-send-email-matthew.garrett@nebula.com> X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 2001:470:1f07:1371:e0f4:3a1:9c35:d688 X-SA-Exim-Mail-From: matthew.garrett@nebula.com X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org 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 --- 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; /*