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]

Message-Id: <1510790701.3711.359.camel@linux.vnet.ibm.com>
Date:   Wed, 15 Nov 2017 19:05:01 -0500
From:   Mimi Zohar <zohar@...ux.vnet.ibm.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Johannes Berg <johannes@...solutions.net>,
        Matthew Garrett <mjg59@...gle.com>,
        David Howells <dhowells@...hat.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        "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 Wed, 2017-11-15 at 21:46 +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 15, 2017 at 02:56:57PM -0500, Mimi Zohar wrote:
> > On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote:
> > > On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:
> > > > On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:
> > > > 
> > > > > Johannes made cfg80211 recently just use request_firmware() now via commit on
> > > > > linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0] as
> > > > > he got tired of waiting firmware signing, but note he implemented a signature
> > > > > checking on its own so he open codes verify_pkcs7_signature() after the
> > > > > request_firmware() call. If we are happy to live with this, then so be it.
> > > > > 
> > > > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=90a53e4432b12288316efaa5f308adafb8d304b0
> > > > 
> > > > Johannes was tired of waiting?  Commit 5a9196d "ima: add support for
> > > > measuring and appraising firmware" has been in the kernel since linux-
> > > > 3.17.
> > > > 
> > > > The original firmware hook for verifying firmware signatures were
> > > > replaced with the common LSM pre and post kernel_read_file() hooks
> > > > in linux-4.6.y.
> > > > 
> > > > Even if you wanted to support firmware signature verification without
> > > > IMA-appraisal, it should be using the LSM hooks.
> > > 
> > > request_firmware() uses kernel_read_file_from_path() underneath the hood,
> > > and so its used for both:
> > > 
> > > 	/lib/firmware/regulatory.db
> > > 	/lib/firmware/regulatory.db.p7s
> > 
> > The firmware signature validation should occur as part of
> > kernel_read_file_from_path(), not as a stand alone verification.
> > 
> > Why not extend kernel_read_file_from_path() to pass the detached signature?
> > Since the signature would only be used for the verification, there's no need
> > to return the open file descriptor.
> 
> This goes along with the question if there were an other users who wanted it,
> or more importantly -- if firmware signing was desirable for any reason, a
> modified kernel_read_file_from_path_signed() could in turn be used, *or* an LSM
> added to handle READING_FIRMWARE and READING_FIRMWARE_PREALLOC_BUFFER.  The
> above use case was one example outside of the typical firmware use.  I've long
> pointed out that we no longer use the firmware API for just firmware, and the
> above is now a very good example of it. I've been suggesting uses of the
> firmware API for non-firmware had already happened and that more uses were on
> its way. Trusted boot has nothing to do with these uses as such the gains of
> systems pegged with "trusted boot" have nothing to do validation of these files
> through hardware.

No, it has nothing to do with other users wanting it.  It has to do
with extending an API to support detach signatures.

There's no reason to define a new function named
kernel_read_file_from_path_signed().  To prevent code duplication, the
existing functions would turn into wrappers.  It's not like there are
that many users.  A quick search returned:

kernel_read_file_from_fd:  2
kernel_read_file_from_path: 5
LSMs: 3 loadpin, selinux, + ima

Mimi