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 11:58:20 -0800
From:   Matthew Garrett <mjg59@...gle.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "AKASHI, Takahiro" <takahiro.akashi@...aro.org>,
        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>
Subject: Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

On Tue, Nov 14, 2017 at 9:34 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> It's this insane "firmware is special" that I disagree with. It's not
> special at all.

Our ability to determine that userland hasn't been tampered with
depends on the kernel being trustworthy. If userland can upload
arbitrary firmware to DMA-capable devices then we can no longer trust
the kernel. So yes, firmware is special.

Here's an example: we have a signed initramfs that's loaded by a
signed bootloader. That initramfs sets up a trustworthy audit chain
and loads an LSM policy that prevents the rest of userland from
interfering with it. From that point on, we don't care about the rest
of userland being signed - we know it can't interfere with us, but we
can reliably inspect what it's doing. Even an offline attack can't do
any damage, since the audit code is still signed. However, the
LSM-imposed boundary depends on the kernel being trustworthy. If an
attacker can replace the firmware that's uploaded to a device that can
do arbitrary DMA then they can tamper with the supposedly trustworthy
audit code and provide false information. Being able to tamper with
the contents of /usr/bin/* doesn't give them that.