[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1363785354.2553.15.camel@x230.sbx07502.somerma.wayport.net>
Date: Wed, 20 Mar 2013 13:15:55 +0000
From: Matthew Garrett <matthew.garrett@...ula.com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH 01/12] Security: Add CAP_COMPROMISE_KERNEL
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@...f.ucam.org
Powered by blists - more mailing lists