diff for duplicates of <87mv02c65y.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index 4f2390f..7c703c2 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -4,12 +4,12 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> > > configuration that IMA has a reasonable expectation of seeing all of >> > > the changes it would be nice if we can say please trust this mount. >> > ->> > IMA has no way of detecting file change. This was one of the reasons +>> > IMA has no way of detecting file change. ?This was one of the reasons >> > for the original patch set's not using the cached IMA results. >> > >> > Even in the case of a trusted mounter and not using IMA cached >> > results, there are no guarantees that the data read to calculate the ->> > file hash, will be the same as what is subsequently read. In some +>> > file hash, will be the same as what is subsequently read. ?In some >> > environments this might be an acceptable risk, while in others not. >> >> So for the cases where it's not, there should be an IMA option or policy @@ -17,7 +17,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and >> SB_I_UNTRUSTED_MOUNTER must be true to not trust, right? > -> Right. To summarize, we've identified 3 scenarios: +> Right. ?To summarize, we've identified 3 scenarios: > 1. Fail signature verification on unprivileged non-init root mounted > file systems. > @@ -25,7 +25,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > (always enabled) > > 2. Permit signature verification on privileged file system mounts in a -> secure system environment. Willing to accept the risk. Does not rely +> secure system environment. ?Willing to accept the risk. ?Does not rely > on cached integrity results, but forces re-evaluation. > > flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or @@ -65,3 +65,7 @@ filesystem. Mimi do you agree or am I missing something? Eric +-- +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 6bdd905..1b1b433 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,18 +7,9 @@ "ref\020180220201636.GA1565@mail.hallyn.com\0" "ref\01519224379.3736.154.camel@linux.vnet.ibm.com\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0Re: [PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" + "Subject\0[PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" "Date\0Wed, 21 Feb 2018 16:46:33 -0600\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Cc\0Serge E. Hallyn <serge@hallyn.com>" - James Morris <jmorris@namei.org> - linux-integrity@vger.kernel.org - linux-security-module@vger.kernel.org - linux-fsdevel@vger.kernel.org - Miklos Szeredi <miklos@szeredi.hu> - Seth Forshee <seth.forshee@canonical.com> - Dongsu Park <dongsu@kinvolk.io> - " Alban Crequy <alban@kinvolk.io>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "Mimi Zohar <zohar@linux.vnet.ibm.com> writes:\n" @@ -27,12 +18,12 @@ ">> > > configuration that IMA has a reasonable expectation of seeing all of\n" ">> > > the changes it would be nice if we can say please trust this mount.\n" ">> > \n" - ">> > IMA has no way of detecting file change. This was one of the reasons\n" + ">> > IMA has no way of detecting file change. ?This was one of the reasons\n" ">> > for the original patch set's not using the cached IMA results.\n" ">> > \n" ">> > Even in the case of a trusted mounter and not using IMA cached\n" ">> > results, there are no guarantees that the data read to calculate the\n" - ">> > file hash, will be the same as what is subsequently read. In some\n" + ">> > file hash, will be the same as what is subsequently read. ?In some\n" ">> > environments this might be an acceptable risk, while in others not.\n" ">> \n" ">> So for the cases where it's not, there should be an IMA option or policy\n" @@ -40,7 +31,7 @@ ">> trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and\n" ">> SB_I_UNTRUSTED_MOUNTER must be true to not trust, right?\n" ">\n" - "> Right. To summarize, we've identified 3 scenarios:\n" + "> Right. ?To summarize, we've identified 3 scenarios:\n" "> 1. Fail signature verification on unprivileged non-init root mounted\n" "> file systems.\n" ">\n" @@ -48,7 +39,7 @@ "> (always enabled)\n" ">\n" "> 2. Permit signature verification on privileged file system mounts in a\n" - "> secure system environment. Willing to accept the risk. Does not rely\n" + "> secure system environment. ?Willing to accept the risk. ?Does not rely\n" "> on cached integrity results, but forces re-evaluation.\n" ">\n" "> flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or\n" @@ -87,6 +78,10 @@ "\n" "Mimi do you agree or am I missing something?\n" "\n" - Eric + "Eric\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 -169715f86c4432eddc302abdc651656974fb193b39ba5b84825de71bc62291b8 +671fa74bd3c83b262ffc6241f5aa6c54358d4ecd4e276a49b79ea4b2b8aa95f2
diff --git a/a/1.txt b/N2/1.txt index 4f2390f..52ebce5 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -4,12 +4,12 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> > > configuration that IMA has a reasonable expectation of seeing all of >> > > the changes it would be nice if we can say please trust this mount. >> > ->> > IMA has no way of detecting file change. This was one of the reasons +>> > IMA has no way of detecting file change. This was one of the reasons >> > for the original patch set's not using the cached IMA results. >> > >> > Even in the case of a trusted mounter and not using IMA cached >> > results, there are no guarantees that the data read to calculate the ->> > file hash, will be the same as what is subsequently read. In some +>> > file hash, will be the same as what is subsequently read. In some >> > environments this might be an acceptable risk, while in others not. >> >> So for the cases where it's not, there should be an IMA option or policy @@ -17,7 +17,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and >> SB_I_UNTRUSTED_MOUNTER must be true to not trust, right? > -> Right. To summarize, we've identified 3 scenarios: +> Right. To summarize, we've identified 3 scenarios: > 1. Fail signature verification on unprivileged non-init root mounted > file systems. > @@ -25,7 +25,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > (always enabled) > > 2. Permit signature verification on privileged file system mounts in a -> secure system environment. Willing to accept the risk. Does not rely +> secure system environment. Willing to accept the risk. Does not rely > on cached integrity results, but forces re-evaluation. > > flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or diff --git a/a/content_digest b/N2/content_digest index 6bdd905..30f4edb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -27,12 +27,12 @@ ">> > > configuration that IMA has a reasonable expectation of seeing all of\n" ">> > > the changes it would be nice if we can say please trust this mount.\n" ">> > \n" - ">> > IMA has no way of detecting file change. This was one of the reasons\n" + ">> > IMA has no way of detecting file change. \302\240This was one of the reasons\n" ">> > for the original patch set's not using the cached IMA results.\n" ">> > \n" ">> > Even in the case of a trusted mounter and not using IMA cached\n" ">> > results, there are no guarantees that the data read to calculate the\n" - ">> > file hash, will be the same as what is subsequently read. In some\n" + ">> > file hash, will be the same as what is subsequently read. \302\240In some\n" ">> > environments this might be an acceptable risk, while in others not.\n" ">> \n" ">> So for the cases where it's not, there should be an IMA option or policy\n" @@ -40,7 +40,7 @@ ">> trusted, with the default being both SB_I_IMA_UNVERIFIABLE_SIGNATURES and\n" ">> SB_I_UNTRUSTED_MOUNTER must be true to not trust, right?\n" ">\n" - "> Right. To summarize, we've identified 3 scenarios:\n" + "> Right. \302\240To summarize, we've identified 3 scenarios:\n" "> 1. Fail signature verification on unprivileged non-init root mounted\n" "> file systems.\n" ">\n" @@ -48,7 +48,7 @@ "> (always enabled)\n" ">\n" "> 2. Permit signature verification on privileged file system mounts in a\n" - "> secure system environment. Willing to accept the risk. Does not rely\n" + "> secure system environment. \302\240Willing to accept the risk. \302\240Does not rely\n" "> on cached integrity results, but forces re-evaluation.\n" ">\n" "> flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES, not SB_I_UNTRUSTED_MOUNTER or\n" @@ -89,4 +89,4 @@ "\n" Eric -169715f86c4432eddc302abdc651656974fb193b39ba5b84825de71bc62291b8 +5ecede6cfa99f080d937220cea612a4f85722f177031d477c34cb223f77d4515
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.