linux-kernel - Re: [PATCH 12/12] Add option to automatically set trusted

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <530E6EEA.3080003@zytor.com>
Date:	Wed, 26 Feb 2014 14:47:06 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Matthew Garrett <matthew.garrett@...ula.com>
CC:	linux-kernel@...r.kernel.org, keescook@...omium.org,
	gregkh@...uxfoundation.org, linux-efi@...r.kernel.org,
	jmorris@...ei.org, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 12/12] Add option to automatically set trusted_kernel
 when in Secure Boot mode

On 02/26/2014 02:41 PM, One Thousand Gnomes wrote:
> On Wed, 26 Feb 2014 15:11:13 -0500
> Matthew Garrett <matthew.garrett@...ula.com> wrote:
> 
>> UEFI Secure Boot provides a mechanism for ensuring that the firmware will
>> only load signed bootloaders and kernels. Certain use cases may also
>> require that the kernel prevent userspace from inserting untrusted kernel
>> code at runtime. Add a configuration option that enforces this automatically
>> when enabled.
> 
> I think you have a load more cases to attempt to paper over before you
> even pretend to achieve that goal. Firewire for example. Also it only
> remotely begins to work if you also force CAP_SYS_RAWIO off globally as
> you need to force off things like raw command issuing to various
> controllers (especially as some of that code is written on the basis that
> 'its RAWIO, screw making it secure and doing all the checks we could
> bother with'.
> 
> RAWIO also disables things like CPU msr access - which is also quite
> adequate for subverting a kernel.
> 
> Another issue that needs addressing is firmware. Quite a few of our
> request_firmware cases load device firmware which is not signed into DMA
> capable hardware. Probably also worth checking what the
> architectural guarantees on bogus microcode updates is. Maybe we need
> firmware signing for such cases to match the mod signing ?
> 
> I'm trying to think what else. Possibly disabling it on Pentium-M with
> the rep movs erratum (Y19) as it's quite possible to set up suitable
> adjacent page sets in user space via the graphics.
> 

I have been arguing for a long time that this should disable RAWIO.  The
argument was that apparently some SCSI controllers started requiring
RAWIO to do things like update firmware... which is arguably equally
problematic, but either way is (a) clearly wrong and (b) started a long,
never-ending discussion...

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/