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:

quoted

On Wed, 2017-11-15 at 18:52 +0100, Luis R. Rodriguez wrote:

quoted

On Wed, Nov 15, 2017 at 06:49:57AM -0500, Mimi Zohar wrote:

quoted

On Tue, 2017-11-14 at 21:50 +0100, Luis R. Rodriguez wrote:

quoted

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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html