LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <firstname.lastname@example.org>
To: Mimi Zohar <email@example.com>,
Matthew Garrett <firstname.lastname@example.org>,
Peter Jones <email@example.com>,
"AKASHI, Takahiro" <firstname.lastname@example.org>,
David Howells <email@example.com>
Cc: "Luis R. Rodriguez" <firstname.lastname@example.org>,
Kalle Valo <email@example.com>,
Seth Forshee <firstname.lastname@example.org>,
Johannes Berg <email@example.com>,
Hans de Goede <firstname.lastname@example.org>,
Ard Biesheuvel <email@example.com>,
firstname.lastname@example.org, Kees Cook <email@example.com>,
Greg Kroah-Hartman <firstname.lastname@example.org>,
Andres Rodriguez <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
Andy Lutomirski <email@example.com>
Subject: Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware
Date: Wed, 9 May 2018 23:48:14 +0000 [thread overview]
Message-ID: <20180509234814.GY27853@wotan.suse.de> (raw)
On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote:
> On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote:
> > OK, its still not clear to what it will do. If it does not touch the firmware
> > loader code, and it just sets and configures IMA to do file signature checking
> > on its own, then yes I think both mechanisms would be doing the similar work.
> > Wouldn't IMA do file signature checks then for all files? Or it would just
> > enable this for whatever files userspace wishes to cover?
> Enabling CONFIG_IMA_APPRAISE_FIRMWARE would enforce firmware
> signatures on all directly loaded firmware and fail any method of
> loading firmware that the signature couldn't be verified.
Ah, so a generic firmware signing mechanism via IMA. Sounds very sensible to me.
Specially in light of the fact that its what we recommend folks to consider
if they need to address firmware signing for devices which do not have the
ability to do hardware firmware signing verification on their own.
> > One of the things with READING_FIRMWARE_REGULATORY_DB is to also use and trust
> > the wireless-regdgb maintainer's key for this file, could IMA be configured to
> > do that?
> IMA has its own trusted keyring. So either the maintainer's key would
> need to be added to the IMA keyring,
I see so we'd need this documented somehow.
> or IMA-appraisal would need to use the regdb keyring.
Can you describe this a bit more, for those not too familiar with IMA, in terms
of what would be involved in the kernel? Or is this all userspace configuration
> > Because that would be one difference here. The whole point of adding
> > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB was to replace CRDA which is a userspace
> > component which checks the signature of regulatory.db before reading it and
> > passing data to the kernel from it.
> > Now, however silly it may be to have CONFIG_IMA_APPRAISE_FIRMWARE *and*
> > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, is your intent in this new patch set
> > you are mentioning, to still enable both to co-exist?
> At build, either CONFIG_CFG80211_REQUIRE_SIGNED_REGDB or
> CONFIG_IMA_APPRAISE_FIRMWARE, where IMA is appraising all firwmare,
> would be enabled, not both.
> > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM
> > > would differentiate between other firmware and the regulatory.db based
> > > on the firmware's pathname.
> > If that is the only way then it would be silly to do the mini LSM as all
> > calls would have to have the check. A special LSM hook for just the
> > regulatory db also doesn't make much sense.
> All calls to request_firmware() are already going through this LSM
> hook. I should have said, it would be based on both READING_FIRMWARE
> and the firmware's pathname.
Yes, but it would still be a strcmp() computation added for all
READING_FIRMWARE. In that sense, the current arrangement is only open coding the
signature verification for the regulatory.db file. One way to avoid this would
be to add an LSM specific to the regulatory db and have the
security_check_regulatory_db() do what it needs per LSM, but that would mean
setting a precedent for open possibly open coded future firmware verification
call. Its not too crazy to consider if an end goal may be avoid further open
coded firmware signature verification hacks.
> > > Making regdb an LSM would have the same issues as currently - deciding
> > > if regdb, IMA-appraisal, or both verify the regdb's signature.
> > Its unclear to me why they can't co-exist yet and not have to touch
> > the firmware_loader code at all.
> With the changes discussed above, they will co-exist. Other than the
> Kconfig changes, I don't think it will touch the firmware_loader code.
next prev parent reply other threads:[~2018-05-09 23:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-01 13:48 [PATCH 0/6] firmware: kernel signature verification Mimi Zohar
2018-05-01 13:48 ` [PATCH 1/6] firmware: permit LSMs and IMA to fail firmware sysfs fallback loading Mimi Zohar
2018-05-04 0:02 ` Luis R. Rodriguez
2018-05-04 0:36 ` Mimi Zohar
2018-05-01 13:48 ` [PATCH 2/6] ima: prevent sysfs fallback firmware loading Mimi Zohar
2018-05-04 0:06 ` Luis R. Rodriguez
2018-05-01 13:48 ` [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware Mimi Zohar
2018-05-04 0:07 ` Luis R. Rodriguez
2018-05-04 0:24 ` Mimi Zohar
2018-05-08 17:34 ` Luis R. Rodriguez
2018-05-09 11:30 ` Mimi Zohar
2018-05-09 19:15 ` Luis R. Rodriguez
2018-05-09 19:57 ` Mimi Zohar
2018-05-09 21:22 ` Luis R. Rodriguez
2018-05-09 22:06 ` Mimi Zohar
2018-05-09 23:48 ` Luis R. Rodriguez [this message]
2018-05-10 2:00 ` Mimi Zohar
2018-05-10 23:26 ` Luis R. Rodriguez
2018-05-11 5:00 ` Mimi Zohar
2018-05-11 21:52 ` Luis R. Rodriguez
2018-05-14 12:58 ` Mimi Zohar
2018-05-14 19:28 ` Luis R. Rodriguez
2018-05-15 2:02 ` Mimi Zohar
2018-05-15 3:26 ` Luis R. Rodriguez
2018-05-15 12:32 ` Josh Boyer
2018-05-15 12:43 ` Mimi Zohar
2018-05-01 13:48 ` [PATCH 4/6] ima: coordinate with signed regulatory.db Mimi Zohar
2018-05-01 13:48 ` [PATCH 5/6] ima: verify kernel firmware signatures when using a preallocated buffer Mimi Zohar
2018-05-01 13:48 ` [RFC PATCH 6/6] ima: prevent loading firmware into a pre-allocated buffer Mimi Zohar
2018-05-04 0:10 ` Luis R. Rodriguez
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).