Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757132Ab3CTNRQ (ORCPT ); Wed, 20 Mar 2013 09:17:16 -0400 Received: from [213.199.154.205] ([213.199.154.205]:23374 "EHLO am1outboundpool.messaging.microsoft.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751711Ab3CTNRO (ORCPT ); Wed, 20 Mar 2013 09:17:14 -0400 X-Forefront-Antispam-Report: CIP:157.56.236.101;KIP:(null);UIP:(null);IPV:NLI;H:BY2PRD0510HT003.namprd05.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zz98dI936eIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dhz2fh2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1155h) From: Matthew Garrett To: "H. Peter Anvin" CC: "linux-kernel@vger.kernel.org" , "linux-security-module@vger.kernel.org" , "linux-efi@vger.kernel.org" , "kexec@lists.infradead.org" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Thread-Topic: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL Thread-Index: AQHOJCAqmvU0usyXI0yxxCAslUbX+ZitxQyAgADMzQA= Date: Wed, 20 Mar 2013 13:15:55 +0000 Message-ID: <1363785354.2553.15.camel@x230.sbx07502.somerma.wayport.net> References: <1363642353-30749-1-git-send-email-matthew.garrett@nebula.com> <51490ABD.3050205@zytor.com> In-Reply-To: <51490ABD.3050205@zytor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.84.4] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-OriginatorOrg: nebula.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id r2KDHHGl032157 Content-Length: 883 Lines: 16 On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote: > Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility > of compromising the kernel, because they let device drivers be bypassed, > which means arbitrary DMA, which means you have everything. Having checked again, I don't think this is true. The most obvious case is libata, which uses CAP_SYS_RAWIO to limit the ability to send raw ATA commands. Being able to do so clearly permits userspace to avoid any kind of policy the vfs has put in place, but there's no obvious way for the user to modify the running kernel. Are you suggesting that removing the CAP_SYS_RAWIO check there would be reasonable? -- Matthew Garrett | mjg59@srcf.ucam.org ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?