diff for duplicates of <20180220201636.GA1565@mail.hallyn.com> diff --git a/a/1.txt b/N1/1.txt index 8a021ea..75003c6 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,4 +1,4 @@ -Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): +Quoting Mimi Zohar (zohar at linux.vnet.ibm.com): > On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote: > > James Morris <jmorris@namei.org> writes: > > @@ -49,7 +49,7 @@ Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES. > > The file signatures are always unverifiable, whether it is mounted by -> root or an unprivileged user. This flag would always be set. +> root or an unprivileged user. ?This flag would always be set. > > > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER. > > For the times when it is not the global root user who mounts @@ -67,12 +67,12 @@ Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > > 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 @@ -86,8 +86,12 @@ SB_I_UNTRUSTED_MOUNTER must be true to not trust, right? > > am mounting a filesystem. > > The latest version of this patch relies on a builtin IMA policy to set -> a flag. No other changes are required to the IMA policy. This +> a flag. ?No other changes are required to the IMA policy. ?This > builtin policy could be used for environments not willing to accept > the default unverifiable signature risk. iiuc that sounds good. +-- +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 12a952d..0099de3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -4,23 +4,13 @@ "ref\0alpine.LRH.2.21.1802201152240.883@namei.org\0" "ref\087tvucifji.fsf@xmission.com\0" "ref\01519135329.3736.88.camel@linux.vnet.ibm.com\0" - "From\0Serge E. Hallyn <serge@hallyn.com>\0" - "Subject\0Re: [PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" + "From\0serge@hallyn.com (Serge E. Hallyn)\0" + "Subject\0[PATCH v1 1/2] ima: fail signature verification on untrusted filesystems\0" "Date\0Tue, 20 Feb 2018 14:16:36 -0600\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Cc\0Eric W. Biederman <ebiederm@xmission.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> - " Serge E . Hallyn <serge@hallyn.com>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" - "Quoting Mimi Zohar (zohar@linux.vnet.ibm.com):\n" + "Quoting Mimi Zohar (zohar at linux.vnet.ibm.com):\n" "> On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote:\n" "> > James Morris <jmorris@namei.org> writes:\n" "> > \n" @@ -71,7 +61,7 @@ "> > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.\n" "> \n" "> The file signatures are always unverifiable, whether it is mounted by\n" - "> root or an unprivileged user. This flag would always be set.\n" + "> root or an unprivileged user. ?This flag would always be set.\n" "> \n" "> > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.\n" "> > For the times when it is not the global root user who mounts\n" @@ -89,12 +79,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" @@ -108,10 +98,14 @@ "> > am mounting a filesystem.\n" "> \n" "> The latest version of this patch relies on a builtin IMA policy to set\n" - "> a flag. No other changes are required to the IMA policy. This\n" + "> a flag. ?No other changes are required to the IMA policy. ?This\n" "> builtin policy could be used for environments not willing to accept\n" "> the default unverifiable signature risk.\n" "\n" - iiuc that sounds good. + "iiuc that sounds good.\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 -1783ea65958990a0e2b20fa741af155543d930f267a83f166af11af91dc1ca41 +0b6c2527b65dcadd5bfc112b35573ef0c54f24f571f8e0feffbb07ca4738e63d
diff --git a/a/1.txt b/N2/1.txt index 8a021ea..d68f564 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -49,7 +49,7 @@ Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES. > > The file signatures are always unverifiable, whether it is mounted by -> root or an unprivileged user. This flag would always be set. +> root or an unprivileged user. �This flag would always be set. > > > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER. > > For the times when it is not the global root user who mounts @@ -67,12 +67,12 @@ Quoting Mimi Zohar (zohar@linux.vnet.ibm.com): > > 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 @@ -86,7 +86,7 @@ SB_I_UNTRUSTED_MOUNTER must be true to not trust, right? > > am mounting a filesystem. > > The latest version of this patch relies on a builtin IMA policy to set -> a flag. No other changes are required to the IMA policy. This +> a flag. �No other changes are required to the IMA policy. �This > builtin policy could be used for environments not willing to accept > the default unverifiable signature risk. diff --git a/a/content_digest b/N2/content_digest index 12a952d..9112d69 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -71,7 +71,7 @@ "> > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES.\n" "> \n" "> The file signatures are always unverifiable, whether it is mounted by\n" - "> root or an unprivileged user. This flag would always be set.\n" + "> root or an unprivileged user. \303\257\302\277\302\275This flag would always be set.\n" "> \n" "> > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER.\n" "> > For the times when it is not the global root user who mounts\n" @@ -89,12 +89,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. \303\257\302\277\302\275This 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. \303\257\302\277\302\275In 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" @@ -108,10 +108,10 @@ "> > am mounting a filesystem.\n" "> \n" "> The latest version of this patch relies on a builtin IMA policy to set\n" - "> a flag. No other changes are required to the IMA policy. This\n" + "> a flag. \303\257\302\277\302\275No other changes are required to the IMA policy. \303\257\302\277\302\275This\n" "> builtin policy could be used for environments not willing to accept\n" "> the default unverifiable signature risk.\n" "\n" iiuc that sounds good. -1783ea65958990a0e2b20fa741af155543d930f267a83f166af11af91dc1ca41 +ca6c0cf37f4e09faf308c000346bec0d1c15a71f741b86a535fb9b1f5eae155a
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.