diff for duplicates of <1493205679.3908.76.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 4a4695e..61afa67 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -15,8 +15,8 @@ On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote: An appended signature should be another place to look for a signature, when a signature is required, but it shouldn't make a difference where -the signature is located. "imasig" could have implied to look for the -signature in both places - xattr or appended. So the new option is +the signature is located. ?"imasig" could have implied to look for the +signature in both places - xattr or appended. ?So the new option is just a hint - a performance improvement. This might seem picayune, but the difference between "expect" vs. @@ -69,7 +69,7 @@ snip > +#ifdef CONFIG_IMA_APPRAISE_APPENDED_SIG Using "ifdef" in C code is really discouraged. Normally, it is an -indication that the code needs to be re-factored. Assuming we really +indication that the code needs to be re-factored. ?Assuming we really need a new CONFIG option, which I'm not sure that we do, I would move the appended signature code to its own file, define stub functions in ima.h, and update the Makefile. @@ -82,7 +82,7 @@ ima.h, and update the Makefile. > + func_tokens[func]); The policy parsing should prevent defining appended_imasig on -inappropriate hooks. Since the iint->flags might be shared between +inappropriate hooks. ?Since the iint->flags might be shared between hooks, we might still need to test buf, but it could be simplified to: if (!buf && iint->flags & IMA_APPENDED_DIGSIG_REQUIRED) { @@ -99,9 +99,9 @@ if (!buf && iint->flags & IMA_APPENDED_DIGSIG_REQUIRED) { If the appended_sig is just a hint as to where the signature is located, then we should read the xattr, even if IMA_DIGSIG_REQUIRED is -not specified. ima_appraise_measurement() should be updated to +not specified. ?ima_appraise_measurement() should be updated to require a signature if either IMA_DIGSIG_REQUIRED or -IMA_APPENDED_SIGNATURE_REQUIRED are specified. +IMA_APPENDED_SIGNATURE_REQUIRED are specified. ? Part of the confusion might be due to the naming -"IMA_APPENEDED_SIGNATURE_REQUIRED". @@ -111,7 +111,7 @@ Part of the confusion might be due to the naming > + if (!xattr_len && digsig_req != IMA_APPENDED_DIGSIG_REQUIRED) > +#endif /* CONFIG_IMA_APPRAISE_APPENDED_SIG */ -Is limiting the "if" to the ifdef really necessary? +Is limiting the "if" to the ifdef really necessary?? > + /* read 'security.ima' */ > + xattr_len = ima_read_xattr(file_dentry(file), @@ -121,7 +121,7 @@ Is limiting the "if" to the ifdef really necessary? Suppose an appended signature and an xattr both exist (eg. kernel modules), but for some reason the appended signature validation fails. - The code should somehow retry the signature validation with the +?The code should somehow retry the signature validation with the xattr. > hash_algo = ima_get_hash_algo(xattr_value, xattr_len); @@ -132,3 +132,8 @@ xattr are not the same, then we would need to re-calculate the file hash. 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 3f8061a..ec194c8 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,19 +1,9 @@ "ref\01492546666-16615-1-git-send-email-bauerman@linux.vnet.ibm.com\0" "ref\01492546666-16615-7-git-send-email-bauerman@linux.vnet.ibm.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH 6/6] ima: Support appended signatures for appraisal\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH 6/6] ima: Support appended signatures for appraisal\0" "Date\0Wed, 26 Apr 2017 07:21:19 -0400\0" - "To\0Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>" - " linux-security-module@vger.kernel.org\0" - "Cc\0linux-ima-devel@lists.sourceforge.net" - keyrings@vger.kernel.org - linux-crypto@vger.kernel.org - linux-kernel@vger.kernel.org - Dmitry Kasatkin <dmitry.kasatkin@gmail.com> - David Howells <dhowells@redhat.com> - Herbert Xu <herbert@gondor.apana.org.au> - David S. Miller <davem@davemloft.net> - " Claudio Carvalho <cclaudio@linux.vnet.ibm.com>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "Hi Thiago,\n" @@ -33,8 +23,8 @@ "\n" "An appended signature should be another place to look for a signature,\n" "when a signature is required, but it shouldn't make a difference where\n" - "the signature is located. \302\240\"imasig\" could have implied to look for the\n" - "signature in both places - xattr or appended. \302\240So the new option is\n" + "the signature is located. ?\"imasig\" could have implied to look for the\n" + "signature in both places - xattr or appended. ?So the new option is\n" "just a hint - a performance improvement.\n" "\n" "This might seem picayune, but the difference between \"expect\" vs.\n" @@ -87,7 +77,7 @@ "> +#ifdef CONFIG_IMA_APPRAISE_APPENDED_SIG\n" "\n" "Using \"ifdef\" in C code is really discouraged. Normally, it is an\n" - "indication that the code needs to be re-factored. \302\240Assuming we really\n" + "indication that the code needs to be re-factored. ?Assuming we really\n" "need a new CONFIG option, which I'm not sure that we do, I would move\n" "the appended signature code to its own file, define stub functions in\n" "ima.h, and update the Makefile.\n" @@ -100,7 +90,7 @@ "> +\t\t\t\t func_tokens[func]);\n" "\n" "The policy parsing should prevent defining appended_imasig on\n" - "inappropriate hooks. \302\240Since the iint->flags might be shared between\n" + "inappropriate hooks. ?Since the iint->flags might be shared between\n" "hooks, we might still need to test buf, but it could be simplified to:\n" "\n" "if (!buf && iint->flags & IMA_APPENDED_DIGSIG_REQUIRED) {\n" @@ -117,9 +107,9 @@ "\n" "If the appended_sig is just a hint as to where the signature is\n" "located, then we should read the xattr, even if IMA_DIGSIG_REQUIRED is\n" - "not specified. \302\240ima_appraise_measurement() should be updated to\n" + "not specified. ?ima_appraise_measurement() should be updated to\n" "require a signature if either IMA_DIGSIG_REQUIRED or\n" - "IMA_APPENDED_SIGNATURE_REQUIRED are specified. \302\240\n" + "IMA_APPENDED_SIGNATURE_REQUIRED are specified. ?\n" "\n" "Part of the confusion might be due to the naming\n" "-\"IMA_APPENEDED_SIGNATURE_REQUIRED\".\n" @@ -129,7 +119,7 @@ "> +\t\tif (!xattr_len && digsig_req != IMA_APPENDED_DIGSIG_REQUIRED)\n" "> +#endif /* CONFIG_IMA_APPRAISE_APPENDED_SIG */\n" "\n" - "Is limiting the \"if\" to the ifdef really necessary?\302\240\n" + "Is limiting the \"if\" to the ifdef really necessary??\n" "\n" "> +\t\t\t/* read 'security.ima' */\n" "> +\t\t\txattr_len = ima_read_xattr(file_dentry(file),\n" @@ -139,7 +129,7 @@ "\n" "Suppose an appended signature and an xattr both exist (eg. kernel\n" "modules), but for some reason the appended signature validation fails.\n" - "\302\240The code should somehow retry the signature validation with the\n" + "?The code should somehow retry the signature validation with the\n" "xattr.\n" "\n" "> \thash_algo = ima_get_hash_algo(xattr_value, xattr_len);\n" @@ -149,6 +139,11 @@ "xattr are not the same, then we would need to re-calculate the file\n" "hash.\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 -92280e22e92cba6d6839efcac50489f40d3eb9e7e42b9adeddf61c5d49de2a21 +fcc1d1526cb7a20534073961d9da7d29d3b920e029c9fa0e84020c74c4677e53
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.