diff for duplicates of <87r2peaqf0.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index 5db6191..bf153b8 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,12 +7,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 @@ -20,7 +20,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. >> > @@ -28,7 +28,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 @@ -69,7 +69,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > > This simply sounds like a performance improvement to the second > scenario, where instead of *always* forcing re-validation, it checks -> the i_version. Perhaps based on a different flag. +> the i_version. ?Perhaps based on a different flag. As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES is set, which implies that the filesystem is lacking something for IMA @@ -88,3 +88,7 @@ I add the fourth case so that we can get a solid definition of SB_I_IMA_UNVERIFIABLE_SIGNATURES. 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 a91650d..deef58d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,18 +9,9 @@ "ref\087mv02c65y.fsf@xmission.com\0" "ref\01519253867.19593.25.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 17:12:03 -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" @@ -32,12 +23,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" @@ -45,7 +36,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" @@ -53,7 +44,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" @@ -94,7 +85,7 @@ ">\n" "> This simply sounds like a performance improvement to the second\n" "> scenario, where instead of *always* forcing re-validation, it checks\n" - "> the i_version. Perhaps based on a different flag.\n" + "> the i_version. ?Perhaps based on a different flag.\n" "\n" "As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES\n" "is set, which implies that the filesystem is lacking something for IMA\n" @@ -112,6 +103,10 @@ "I add the fourth case so that we can get a solid definition of\n" "SB_I_IMA_UNVERIFIABLE_SIGNATURES.\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 -fb070071d21ea6ae971672825b5407e0c54ebfad25743d6c5ee199076f413521 +399b8feabead46666b7cf48af5c86d6c642d51f4fae0aa894d9ab22d813fb81a
diff --git a/a/1.txt b/N2/1.txt index 5db6191..98ab5f5 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -7,12 +7,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 @@ -20,7 +20,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. >> > @@ -28,7 +28,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 @@ -69,7 +69,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > > This simply sounds like a performance improvement to the second > scenario, where instead of *always* forcing re-validation, it checks -> the i_version. Perhaps based on a different flag. +> the i_version. Perhaps based on a different flag. As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES is set, which implies that the filesystem is lacking something for IMA diff --git a/a/content_digest b/N2/content_digest index a91650d..19f84cd 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -32,12 +32,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" @@ -45,7 +45,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" @@ -53,7 +53,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" @@ -94,7 +94,7 @@ ">\n" "> This simply sounds like a performance improvement to the second\n" "> scenario, where instead of *always* forcing re-validation, it checks\n" - "> the i_version. Perhaps based on a different flag.\n" + "> the i_version. \302\240Perhaps based on a different flag.\n" "\n" "As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES\n" "is set, which implies that the filesystem is lacking something for IMA\n" @@ -114,4 +114,4 @@ "\n" Eric -fb070071d21ea6ae971672825b5407e0c54ebfad25743d6c5ee199076f413521 +d67b1a75bfac7c1b35ab99c8ae1a5adbdef5f80307a8b0ae3226bbb798e8fdbd
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.