diff for duplicates of <1525903617.3551.281.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 7dfdd49..e4e196c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,7 +2,7 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > 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. +> > > > > >?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 @@ -12,13 +12,13 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > > > > > 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 +> > > > 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 +> > 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 @@ -28,7 +28,7 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > > > > > *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 +> > > > 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. @@ -54,10 +54,10 @@ loading firmware that the signature couldn't be verified. > 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 +IMA has its own trusted keyring. ?So either the maintainer's key would need to be added to the IMA keyring, or IMA-appraisal would need to use the regdb keyring. - +?? > 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 @@ -72,7 +72,7 @@ CONFIG_IMA_APPRAISE_FIRMWARE, where IMA is appraising all firwmare, would be enabled, not both. The builtin IMA-policies could be replaced with a custom policy, -requiring firmware signature verification. In that case, the regdb +requiring firmware signature verification. ?In that case, the regdb signature would be verified twice. > @@ -93,7 +93,7 @@ signature would be verified twice. > > > > > > > > 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 +> > > > 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. @@ -101,7 +101,7 @@ signature would be verified twice. > > > 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 +> > 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. > @@ -110,7 +110,7 @@ signature would be verified twice. > 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 +hook. ?I should have said, it would be based on both READING_FIRMWARE and the firmware's pathname. > @@ -120,7 +120,12 @@ and the firmware's pathname. > 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 +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. 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 diff --git a/a/content_digest b/N1/content_digest index 72c0b19..6d56a66 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,33 +7,17 @@ "ref\020180509191508.GR27853@wotan.suse.de\0" "ref\01525895838.3551.247.camel@linux.vnet.ibm.com\0" "ref\020180509212212.GX27853@wotan.suse.de\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware\0" "Date\0Wed, 09 May 2018 18:06:57 -0400\0" - "To\0Luis R. Rodriguez <mcgrof@kernel.org>\0" - "Cc\0linux-wireless <linux-wireless@vger.kernel.org>" - Kalle Valo <kvalo@codeaurora.org> - Seth Forshee <seth.forshee@canonical.com> - Johannes Berg <johannes.berg@intel.com> - linux-integrity@vger.kernel.org - Hans de Goede <hdegoede@redhat.com> - Ard Biesheuvel <ard.biesheuvel@linaro.org> - Peter Jones <pjones@redhat.com> - linux-security-module@vger.kernel.org - linux-kernel@vger.kernel.org - David Howells <dhowells@redhat.com> - Kees Cook <keescook@chromium.org> - Greg Kroah-Hartman <gregkh@linuxfoundation.org> - Andres Rodriguez <andresx7@gmail.com> - Linus Torvalds <torvalds@linux-foundation.org> - " Andy Lutomirski <luto@kernel.org>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote:\n" "> On Wed, May 09, 2018 at 03:57:18PM -0400, Mimi Zohar wrote:\n" "> > On Wed, 2018-05-09 at 19:15 +0000, Luis R. Rodriguez wrote:\n" "> > \n" - "> > > > > > If both are enabled, do we require both signatures or is one enough.\n" + "> > > > > >?If both are enabled, do we require both signatures or is one enough.\n" "> > > > > \n" "> > > > > Good question. Considering it as a stacked LSM (although not implemented\n" "> > > > > as one), I'd say its up to who enabled the Kconfig entries. If IMA and\n" @@ -43,13 +27,13 @@ "> > > > > system integrator to decide.\n" "> > > > \n" "> > > > Just because IMA-appraisal is enabled in the kernel doesn't mean that\n" - "> > > > firmware signatures will be verified. That is a run time policy\n" + "> > > > firmware signatures will be verified. ?That is a run time policy\n" "> > > > decision.\n" "> > > \n" "> > > Sure, I accept this if IMA does not do signature verification. However\n" "> > > signature verification seems like a stackable LSM decision, no?\n" "> > \n" - "> > IMA-appraisal can be configured to enforce file signatures. Refer to\n" + "> > IMA-appraisal can be configured to enforce file signatures. ?Refer to\n" "> > discussion below as to how.\n" "> > \n" "> > > > > If we however want to make it clear that such things as\n" @@ -59,7 +43,7 @@ "> > > > > *further* kernel signature verification, even though IMA already is sufficient.\n" "> > > > > Perhaps CONFIG_ENABLE_IMA_OVERLAPPING, and the driver depends on it?\n" "> > > > \n" - "> > > > The existing CONFIG_IMA_APPRAISE is not enough. If there was a build\n" + "> > > > The existing CONFIG_IMA_APPRAISE is not enough. ?If there was a build\n" "> > > > time IMA config that translated into an IMA policy requiring firmware\n" "> > > > signature verification (eg. CONFIG_IMA_APPRAISE_FIRMWARE), this could\n" "> > > > be sorted out at build time.\n" @@ -85,10 +69,10 @@ "> the wireless-regdgb maintainer's key for this file, could IMA be configured to\n" "> do that?\n" "\n" - "IMA has its own trusted keyring. So either the maintainer's key would\n" + "IMA has its own trusted keyring. ?So either the maintainer's key would\n" "need to be added to the IMA keyring, or IMA-appraisal would need to\n" "use the regdb keyring.\n" - " \n" + "??\n" "> Because that would be one difference here. The whole point of adding\n" "> CONFIG_CFG80211_REQUIRE_SIGNED_REGDB was to replace CRDA which is a userspace\n" "> component which checks the signature of regulatory.db before reading it and\n" @@ -103,7 +87,7 @@ "would be enabled, not both.\n" "\n" "The builtin IMA-policies could be replaced with a custom policy,\n" - "requiring firmware signature verification. In that case, the regdb\n" + "requiring firmware signature verification. ?In that case, the regdb\n" "signature would be verified twice.\n" "\n" "> \n" @@ -124,7 +108,7 @@ "> > > > \n" "> > > > 2. If CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is configured, not\n" "> > > > \"CONFIG_IMA_APPRAISE_FIRMWARE\", a custom IMA-policy rule that\n" - "> > > > appraises the firmware signature could be defined. In this case, both\n" + "> > > > appraises the firmware signature could be defined. ?In this case, both\n" "> > > > signature verification methods would be enforced.\n" "> > > > \n" "> > > > then READING_FIRMWARE_REGULATORY_DB would not be needed.\n" @@ -132,7 +116,7 @@ "> > > True, however I'm suggesting that CONFIG_CFG80211_REQUIRE_SIGNED_REGDB\n" "> > > could just be a mini subsystem stackable LSM.\n" "> > \n" - "> > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM\n" + "> > Yes, writing regdb as a micro/mini LSM sounds reasonable. ?The LSM\n" "> > would differentiate between other firmware and the regulatory.db based\n" "> > on the firmware's pathname.\n" "> \n" @@ -141,7 +125,7 @@ "> regulatory db also doesn't make much sense.\n" "\n" "All calls to request_firmware() are already going through this LSM\n" - "hook. I should have said, it would be based on both READING_FIRMWARE\n" + "hook. ?I should have said, it would be based on both READING_FIRMWARE\n" "and the firmware's pathname.\n" "\n" "> \n" @@ -151,9 +135,14 @@ "> Its unclear to me why they can't co-exist yet and not have to touch\n" "> the firmware_loader code at all.\n" "\n" - "With the changes discussed above, they will co-exist. Other than the\n" + "With the changes discussed above, they will co-exist. ?Other than the\n" "Kconfig changes, I don't think it will touch the firmware_loader code.\n" "\n" - Mimi + "Mimi\n" + "\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n" + "the body of a message to majordomo at vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -81d38c0002c44098c3546cdd601709e6ff3dad1b7bb13e4ed37a116af296cc6c +f8a39d2ddebe60c2aaa88d75551ecb2d6bddef0ec0ed3a43e2c6a37b9eddbbb7
diff --git a/a/1.txt b/N2/1.txt index 7dfdd49..5af91cc 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,7 +2,7 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > 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. +> > > > > > 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 @@ -12,13 +12,13 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > > > > > 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 +> > > > 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 +> > 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 @@ -28,7 +28,7 @@ On Wed, 2018-05-09 at 21:22 +0000, Luis R. Rodriguez wrote: > > > > > *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 +> > > > 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. @@ -54,10 +54,10 @@ loading firmware that the signature couldn't be verified. > 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 +IMA has its own trusted keyring. So either the maintainer's key would need to be added to the IMA keyring, or IMA-appraisal would need to use the regdb keyring. - + > 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 @@ -72,7 +72,7 @@ CONFIG_IMA_APPRAISE_FIRMWARE, where IMA is appraising all firwmare, would be enabled, not both. The builtin IMA-policies could be replaced with a custom policy, -requiring firmware signature verification. In that case, the regdb +requiring firmware signature verification. In that case, the regdb signature would be verified twice. > @@ -93,7 +93,7 @@ signature would be verified twice. > > > > > > > > 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 +> > > > 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. @@ -101,7 +101,7 @@ signature would be verified twice. > > > 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 +> > 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. > @@ -110,7 +110,7 @@ signature would be verified twice. > 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 +hook. I should have said, it would be based on both READING_FIRMWARE and the firmware's pathname. > @@ -120,7 +120,7 @@ and the firmware's pathname. > 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 +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. Mimi diff --git a/a/content_digest b/N2/content_digest index 72c0b19..5f4c9cb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -33,7 +33,7 @@ "> On Wed, May 09, 2018 at 03:57:18PM -0400, Mimi Zohar wrote:\n" "> > On Wed, 2018-05-09 at 19:15 +0000, Luis R. Rodriguez wrote:\n" "> > \n" - "> > > > > > If both are enabled, do we require both signatures or is one enough.\n" + "> > > > > >\302\240If both are enabled, do we require both signatures or is one enough.\n" "> > > > > \n" "> > > > > Good question. Considering it as a stacked LSM (although not implemented\n" "> > > > > as one), I'd say its up to who enabled the Kconfig entries. If IMA and\n" @@ -43,13 +43,13 @@ "> > > > > system integrator to decide.\n" "> > > > \n" "> > > > Just because IMA-appraisal is enabled in the kernel doesn't mean that\n" - "> > > > firmware signatures will be verified. That is a run time policy\n" + "> > > > firmware signatures will be verified. \302\240That is a run time policy\n" "> > > > decision.\n" "> > > \n" "> > > Sure, I accept this if IMA does not do signature verification. However\n" "> > > signature verification seems like a stackable LSM decision, no?\n" "> > \n" - "> > IMA-appraisal can be configured to enforce file signatures. Refer to\n" + "> > IMA-appraisal can be configured to enforce file signatures. \302\240Refer to\n" "> > discussion below as to how.\n" "> > \n" "> > > > > If we however want to make it clear that such things as\n" @@ -59,7 +59,7 @@ "> > > > > *further* kernel signature verification, even though IMA already is sufficient.\n" "> > > > > Perhaps CONFIG_ENABLE_IMA_OVERLAPPING, and the driver depends on it?\n" "> > > > \n" - "> > > > The existing CONFIG_IMA_APPRAISE is not enough. If there was a build\n" + "> > > > The existing CONFIG_IMA_APPRAISE is not enough. \302\240If there was a build\n" "> > > > time IMA config that translated into an IMA policy requiring firmware\n" "> > > > signature verification (eg. CONFIG_IMA_APPRAISE_FIRMWARE), this could\n" "> > > > be sorted out at build time.\n" @@ -85,10 +85,10 @@ "> the wireless-regdgb maintainer's key for this file, could IMA be configured to\n" "> do that?\n" "\n" - "IMA has its own trusted keyring. So either the maintainer's key would\n" + "IMA has its own trusted keyring. \302\240So either the maintainer's key would\n" "need to be added to the IMA keyring, or IMA-appraisal would need to\n" "use the regdb keyring.\n" - " \n" + "\302\240\302\240\n" "> Because that would be one difference here. The whole point of adding\n" "> CONFIG_CFG80211_REQUIRE_SIGNED_REGDB was to replace CRDA which is a userspace\n" "> component which checks the signature of regulatory.db before reading it and\n" @@ -103,7 +103,7 @@ "would be enabled, not both.\n" "\n" "The builtin IMA-policies could be replaced with a custom policy,\n" - "requiring firmware signature verification. In that case, the regdb\n" + "requiring firmware signature verification. \302\240In that case, the regdb\n" "signature would be verified twice.\n" "\n" "> \n" @@ -124,7 +124,7 @@ "> > > > \n" "> > > > 2. If CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is configured, not\n" "> > > > \"CONFIG_IMA_APPRAISE_FIRMWARE\", a custom IMA-policy rule that\n" - "> > > > appraises the firmware signature could be defined. In this case, both\n" + "> > > > appraises the firmware signature could be defined. \302\240In this case, both\n" "> > > > signature verification methods would be enforced.\n" "> > > > \n" "> > > > then READING_FIRMWARE_REGULATORY_DB would not be needed.\n" @@ -132,7 +132,7 @@ "> > > True, however I'm suggesting that CONFIG_CFG80211_REQUIRE_SIGNED_REGDB\n" "> > > could just be a mini subsystem stackable LSM.\n" "> > \n" - "> > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM\n" + "> > Yes, writing regdb as a micro/mini LSM sounds reasonable. \302\240The LSM\n" "> > would differentiate between other firmware and the regulatory.db based\n" "> > on the firmware's pathname.\n" "> \n" @@ -141,7 +141,7 @@ "> regulatory db also doesn't make much sense.\n" "\n" "All calls to request_firmware() are already going through this LSM\n" - "hook. I should have said, it would be based on both READING_FIRMWARE\n" + "hook. \302\240I should have said, it would be based on both READING_FIRMWARE\n" "and the firmware's pathname.\n" "\n" "> \n" @@ -151,9 +151,9 @@ "> Its unclear to me why they can't co-exist yet and not have to touch\n" "> the firmware_loader code at all.\n" "\n" - "With the changes discussed above, they will co-exist. Other than the\n" + "With the changes discussed above, they will co-exist. \302\240Other than the\n" "Kconfig changes, I don't think it will touch the firmware_loader code.\n" "\n" Mimi -81d38c0002c44098c3546cdd601709e6ff3dad1b7bb13e4ed37a116af296cc6c +9b95dad06e9889eec4f1dcca41958b621edb2ec6772685f05a0ff98ec4468f50
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.