diff for duplicates of <1525865428.3551.175.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index b4feb23..ac21f5f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -40,9 +40,9 @@ On Tue, 2018-05-08 at 17:34 +0000, Luis R. Rodriguez wrote: > files since the firmware API is used. IMA-appraisal can verify a signature stored as an xattr, but not a -detached signature. That support could be added, but isn't there -today. Today, a regulatory.db signature would have to be stored as an -xattr. +detached signature. ?That support could be added, but isn't there +today. ?Today, a regulatory.db signature would have to be stored as an +xattr.? > > As such I see no reason to add a new ID for them at all. @@ -52,7 +52,7 @@ xattr. > stacked LSM. I'd be open to see patches which set that out. May be a > cleaner interface. > -> > 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 @@ -62,7 +62,7 @@ xattr. > 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. > @@ -73,7 +73,7 @@ decision. > *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. @@ -96,7 +96,7 @@ Suppose, 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. @@ -121,10 +121,15 @@ Mimi > > > > The subsequent patch attempts to verify the IMA-appraisal signature, but on > > failure it falls back to allowing regdb signatures. -> > For systems that only want to load firmware based on IMA-appraisal, then +> >?For systems that only want to load firmware based on IMA-appraisal, then > >regdb wouldn't be enabled. > > I think we can codify this a bit better, without a new ID. > > Luis -> +> + +-- +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 a97a379..3ef2f28 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,26 +3,10 @@ "ref\020180504000743.GR27853@wotan.suse.de\0" "ref\01525393466.3539.133.camel@linux.vnet.ibm.com\0" "ref\020180508173404.GG27853@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 07:30:28 -0400\0" - "To\0Luis R. Rodriguez <mcgrof@kernel.org>" - linux-wireless <linux-wireless@vger.kernel.org> - Kalle Valo <kvalo@codeaurora.org> - Seth Forshee <seth.forshee@canonical.com> - " Johannes Berg <johannes.berg@intel.com>\0" - "Cc\0linux-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 Tue, 2018-05-08 at 17:34 +0000, Luis R. Rodriguez wrote:\n" @@ -67,9 +51,9 @@ "> files since the firmware API is used.\n" "\n" "IMA-appraisal can verify a signature stored as an xattr, but not a\n" - "detached signature. That support could be added, but isn't there\n" - "today. Today, a regulatory.db signature would have to be stored as an\n" - "xattr. \n" + "detached signature. ?That support could be added, but isn't there\n" + "today. ?Today, a regulatory.db signature would have to be stored as an\n" + "xattr.?\n" "\n" "> \n" "> As such I see no reason to add a new ID for them at all.\n" @@ -79,7 +63,7 @@ "> stacked LSM. I'd be open to see patches which set that out. May be a\n" "> cleaner interface.\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" @@ -89,7 +73,7 @@ "> 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" "> \n" @@ -100,7 +84,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" @@ -123,7 +107,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" @@ -148,12 +132,17 @@ "> > \n" "> > The subsequent patch attempts to verify the IMA-appraisal signature, but on\n" "> > failure it falls back to allowing regdb signatures. \n" - "> > For systems that only want to load firmware based on IMA-appraisal, then\n" + "> >?For systems that only want to load firmware based on IMA-appraisal, then\n" "> >regdb wouldn't be enabled.\n" "> \n" "> I think we can codify this a bit better, without a new ID.\n" "> \n" "> Luis\n" - > + "> \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 -58fe67d503ebf50013d11c551fc9aeab1e364012014e4d4fac4e190d579fde70 +f8abf9a648346228130548e2a9a5a5e65e05bcfbfa1e17b6de30210140550992
diff --git a/a/1.txt b/N2/1.txt index b4feb23..dbb9bfa 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -40,9 +40,9 @@ On Tue, 2018-05-08 at 17:34 +0000, Luis R. Rodriguez wrote: > files since the firmware API is used. IMA-appraisal can verify a signature stored as an xattr, but not a -detached signature. That support could be added, but isn't there -today. Today, a regulatory.db signature would have to be stored as an -xattr. +detached signature. That support could be added, but isn't there +today. Today, a regulatory.db signature would have to be stored as an +xattr. > > As such I see no reason to add a new ID for them at all. @@ -52,7 +52,7 @@ xattr. > stacked LSM. I'd be open to see patches which set that out. May be a > cleaner interface. > -> > 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 @@ -62,7 +62,7 @@ xattr. > 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. > @@ -73,7 +73,7 @@ decision. > *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. @@ -96,7 +96,7 @@ Suppose, 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. @@ -121,7 +121,7 @@ Mimi > > > > The subsequent patch attempts to verify the IMA-appraisal signature, but on > > failure it falls back to allowing regdb signatures. -> > For systems that only want to load firmware based on IMA-appraisal, then +> > For systems that only want to load firmware based on IMA-appraisal, then > >regdb wouldn't be enabled. > > I think we can codify this a bit better, without a new ID. diff --git a/a/content_digest b/N2/content_digest index a97a379..e7e8c8e 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -67,9 +67,9 @@ "> files since the firmware API is used.\n" "\n" "IMA-appraisal can verify a signature stored as an xattr, but not a\n" - "detached signature. That support could be added, but isn't there\n" - "today. Today, a regulatory.db signature would have to be stored as an\n" - "xattr. \n" + "detached signature. \302\240That support could be added, but isn't there\n" + "today. \302\240Today, a regulatory.db signature would have to be stored as an\n" + "xattr.\302\240\n" "\n" "> \n" "> As such I see no reason to add a new ID for them at all.\n" @@ -79,7 +79,7 @@ "> stacked LSM. I'd be open to see patches which set that out. May be a\n" "> cleaner interface.\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" @@ -89,7 +89,7 @@ "> 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" "> \n" @@ -100,7 +100,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" @@ -123,7 +123,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" @@ -148,7 +148,7 @@ "> > \n" "> > The subsequent patch attempts to verify the IMA-appraisal signature, but on\n" "> > failure it falls back to allowing regdb signatures. \n" - "> > For systems that only want to load firmware based on IMA-appraisal, then\n" + "> >\302\240For systems that only want to load firmware based on IMA-appraisal, then\n" "> >regdb wouldn't be enabled.\n" "> \n" "> I think we can codify this a bit better, without a new ID.\n" @@ -156,4 +156,4 @@ "> Luis\n" > -58fe67d503ebf50013d11c551fc9aeab1e364012014e4d4fac4e190d579fde70 +7909a1be7e4484b07a739dad6273598a8a97a1a7aae07a8f95ee9999a2c95d65
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.