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>
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>,
Peter Jones <firstname.lastname@example.org>,
email@example.com, David Howells <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 21:22:12 +0000 [thread overview]
Message-ID: <20180509212212.GX27853@wotan.suse.de> (raw)
On Wed, May 09, 2018 at 03:57:18PM -0400, Mimi Zohar wrote:
> On Wed, 2018-05-09 at 19:15 +0000, Luis R. Rodriguez wrote:
> > > > > If both are enabled, do we require both signatures or is one enough.
> > > >
> > > > Good question. Considering it as a stacked LSM (although not implemented
> > > > as one), I'd say its up to who enabled the Kconfig entries. If IMA and
> > > > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are enabled then both. If someone enabled
> > > > IMA though, then surely I agree that enabling
> > > > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is stupid and redundant, but its up to the
> > > > system integrator to decide.
> > >
> > > Just because IMA-appraisal is enabled in the kernel doesn't mean that
> > > firmware signatures will be verified. That is a run time policy
> > > decision.
> > Sure, I accept this if IMA does not do signature verification. However
> > signature verification seems like a stackable LSM decision, no?
> IMA-appraisal can be configured to enforce file signatures. Refer to
> discussion below as to how.
> > > > If we however want to make it clear that such things as
> > > > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB are not required when IMA is enabled we
> > > > could just make the kconfig depend on !IMA or something? Or perhaps a new
> > > > kconfig for IMA which if selected it means that drivers can opt to open code
> > > > *further* kernel signature verification, even though IMA already is sufficient.
> > > > Perhaps CONFIG_ENABLE_IMA_OVERLAPPING, and the driver depends on it?
> > >
> > > The existing CONFIG_IMA_APPRAISE is not enough. If there was a build
> > > time IMA config that translated into an IMA policy requiring firmware
> > > signature verification (eg. CONFIG_IMA_APPRAISE_FIRMWARE), this could
> > > be sorted out at build time.
> > I see makes sense.
> Ok, so instead of introducing READING_FIRMWARE_REGULATORY_DB, I'll
> post patches introducing CONFIG_IMA_APPRAISE_FIRMWARE, as described
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?
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
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?
> > > > > Assigning a different id for regdb signed firmware allows LSMs and IMA
> > > > > to handle regdb files differently.
> > > >
> > > > That's not the main concern here, its the precedent we are setting here for
> > > > any new kernel interface which open codes firmware signing on its own. What
> > > > you are doing means other kernel users who open codes their own firmware
> > > > signing may need to add yet-another reading ID. That doesn't either look
> > > > well on code, and seems kind of silly from a coding perspective given
> > > > the above, in which I clarify IMA still is doing its own appraisal on it.
> > >
> > > Suppose,
> > >
> > > 1. Either CONFIG_CFG80211_REQUIRE_SIGNED_REGDB or
> > > "CONFIG_IMA_APPRAISE_FIRMWARE" would be configured at build.
> > >
> > > 2. If CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is configured, not
> > > "CONFIG_IMA_APPRAISE_FIRMWARE", a custom IMA-policy rule that
> > > appraises the firmware signature could be defined. In this case, both
> > > signature verification methods would be enforced.
> > >
> > > then READING_FIRMWARE_REGULATORY_DB would not be needed.
> > True, however I'm suggesting that CONFIG_CFG80211_REQUIRE_SIGNED_REGDB
> > could just be a mini subsystem stackable LSM.
> 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.
> 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.
next prev parent reply other threads:[~2018-05-09 21:22 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 [this message]
2018-05-09 22:06 ` Mimi Zohar
2018-05-09 23:48 ` Luis R. Rodriguez
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).