linux-kernel - Re: Trusted kernel patchset for Secure Boot lockdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1394726363.25122.16.camel@x230>
Date:	Thu, 13 Mar 2014 15:59:24 +0000
From:	Matthew Garrett <matthew.garrett@...ula.com>
To:	"jmorris@...ei.org" <jmorris@...ei.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"linux-security-module@...r.kernel.org" 
	<linux-security-module@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hpa@...or.com" <hpa@...or.com>,
	"jwboyer@...oraproject.org" <jwboyer@...oraproject.org>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Subject: Re: Trusted kernel patchset for Secure Boot lockdown

On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:

> I'll take it, but there's unanswered review feedback (your response to the 
> first question), and Alan raised some doubts about the patches which I'm 
> not sure have been resolved.

The remaining opens seem to be CAP_SYS_RAWIO and firmware signing?
Ironically, disabling CAP_SYS_RAWIO disables firmware loading…

The problem with CAP_SYS_RAWIO is that its semantics were never
sufficiently well documented, and as a result it's a mixture of "This is
incredibly dangerous" and "We replaced a check for uid 0 with whichever
capability seemed to have the most appropriate name". I've gone through
all the uses of CAP_SYS_RAWIO and added additional checks to the generic
ones that seem appropriate. There's a couple of old drivers that use it
to gate access to features that potentially allow arbitrary DMA and it
might be worth cleaning those up, but the only general case I haven't
modified is the ability to send arbitrary SCSI commands from userspace.
My understanding is that endpoints aren't going to be able to DMA to
arbitrary addresses, so that doesn't seem like a problem.

On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
functionality - firmware loading and the fibmap ioctl are probably the
most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
userspace expectations, so we're kind of stuck there.

As for signed firmware, I'm looking forward to Kees' work on that.

-- 
Matthew Garrett <matthew.garrett@...ula.com>