diff for duplicates of <1519253867.19593.25.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index e1d7b93..0abca30 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,12 +5,12 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > >> > > 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 @@ -18,7 +18,7 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > >> 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. > > @@ -26,7 +26,7 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > > (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 @@ -67,6 +67,11 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: 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. -Mimi +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 8500122..c5765f5 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,19 +7,10 @@ "ref\020180220201636.GA1565@mail.hallyn.com\0" "ref\01519224379.3736.154.camel@linux.vnet.ibm.com\0" "ref\087mv02c65y.fsf@xmission.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" "Date\0Wed, 21 Feb 2018 17:57:47 -0500\0" - "To\0Eric W. Biederman <ebiederm@xmission.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" "On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote:\n" @@ -29,12 +20,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" @@ -42,7 +33,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" @@ -50,7 +41,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" @@ -91,8 +82,13 @@ "\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" - 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 -05c4812826dac44064e58a2b680d4f8127b8f20950cb487740be843ac9b9b80f +54a4b11fb494f9a5fdb7c22f4379e7acdfc2696132a2c9929a8b76662bacdaff
diff --git a/a/1.txt b/N2/1.txt index e1d7b93..1431e59 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,12 +5,12 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > >> > > 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 @@ -18,7 +18,7 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > >> 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. > > @@ -26,7 +26,7 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: > > (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 @@ -67,6 +67,6 @@ On Wed, 2018-02-21 at 16:46 -0600, Eric W. Biederman wrote: 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. Mimi diff --git a/a/content_digest b/N2/content_digest index 8500122..56ebf1d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -29,12 +29,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" @@ -42,7 +42,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" @@ -50,7 +50,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" @@ -91,8 +91,8 @@ "\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" Mimi -05c4812826dac44064e58a2b680d4f8127b8f20950cb487740be843ac9b9b80f +e261064d896646947c19fed6453a02014df9ac6c7d2f0cf9e30828f999f58bde
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.