linux-kernel - Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 14 Nov 2017 00:20:47 +0000
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     David Howells <dhowells@...hat.com>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Blunck <jblunck@...radead.org>,
        Julia Lawall <julia.lawall@...6.fr>,
        Marcus Meissner <meissner@...e.de>, Gary Lin <GLin@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Matthew Garrett <mjg59@...gle.com>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel
 lockdown

On Mon, 13 Nov 2017 14:09:10 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Mon, Nov 13, 2017 at 1:44 PM, David Howells <dhowells@...hat.com> wrote:
> >
> > Whilst that may be true, we either have to check signatures on every bit of
> > firmware that the appropriate driver doesn't say is meant to be signed or not
> > bother.  
> 
> I vote for "not bother".
> 
> Seriously, if you have firmware in /lib/firmware, and you don't trust
> it, what the hell are you doing?

Booting a computer 8) - does anyone trust firmware ???


That aside if you can replace the firmware with your own, and your own
firmware compromises the system then you have a privilege escalation from
CAP_SYS_DAC to CAP_SYS_RAWIO just as you do with unsigned modules

(you can't load modules without lots of rights but who cares because you
can simply use cp to put them there with lesser rights and let the kernel
do it).


Alan