From patchwork Mon Mar 18 21:32:22 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Garrett X-Patchwork-Id: 2296191 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 7238CE00E6 for ; Mon, 18 Mar 2013 21:35:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933369Ab3CRVc6 (ORCPT ); Mon, 18 Mar 2013 17:32:58 -0400 Received: from cavan.codon.org.uk ([93.93.128.6]:35926 "EHLO cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933343Ab3CRVcy (ORCPT ); Mon, 18 Mar 2013 17:32:54 -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 1UHhfn-0006Ez-Nh; Mon, 18 Mar 2013 21:32:51 +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 01/12] Security: Add CAP_COMPROMISE_KERNEL Date: Mon, 18 Mar 2013 17:32:22 -0400 Message-Id: <1363642353-30749-1-git-send-email-matthew.garrett@nebula.com> X-Mailer: git-send-email 1.8.1.2 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 Caring about protecting the kernel from UID 0 was previously relatively uninteresting, since an attacker could simply modify the kernel, a module or an earlier part of the boot chain in order to insert new code. However, there are now a range of widely-deployed mechanisms for ensuring the authenticity of the early boot process and kernel. The addition of module signing makes most of these attacks infeasible. This means we can return our focus to the kernel. There's currently a number of kernel interfaces that permit privileged userspace to modify the running kernel. These are currently protected by CAP_SYS_RAWIO, but unfortunately the semantics of this capability are poorly defined and it now covers a large superset of the desired behaviour. This patch introduces CAP_COMPROMISE_KERNEL. Holding this capability indicates that a process is empowered to perform tasks that may result in modification of the running kernel. While aimed at handling the specific use-case of Secure Boot, it is generalisable to any other environment where permitting userspace to modify the kernel is undesirable. Signed-off-by: Matthew Garrett --- include/uapi/linux/capability.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h index ba478fa..7109e650 100644 --- a/include/uapi/linux/capability.h +++ b/include/uapi/linux/capability.h @@ -343,7 +343,11 @@ struct vfs_cap_data { #define CAP_BLOCK_SUSPEND 36 -#define CAP_LAST_CAP CAP_BLOCK_SUSPEND +/* Allow things that trivially permit root to modify the running kernel */ + +#define CAP_COMPROMISE_KERNEL 37 + +#define CAP_LAST_CAP CAP_COMPROMISE_KERNEL #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)