diff for duplicates of <1519255954.3400.16.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 20ce9ae..e40ec2b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -8,12 +8,12 @@ On Wed, 2018-02-21 at 17:12 -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 @@ -21,7 +21,7 @@ On Wed, 2018-02-21 at 17:12 -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. > >> > @@ -29,7 +29,7 @@ On Wed, 2018-02-21 at 17:12 -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 @@ -70,7 +70,7 @@ On Wed, 2018-02-21 at 17:12 -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. > > As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES > is set, which implies that the filesystem is lacking something for IMA @@ -83,7 +83,7 @@ On Wed, 2018-02-21 at 17:12 -0600, Eric W. Biederman wrote: The information might be there, but IMA currently detects a file change and resets the flags only when the last writer calls -__fput(). Any other time, new support would be needed. +__fput().??Any other time, new support would be needed. Mimi @@ -95,4 +95,9 @@ Mimi > 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 691d6bf..0e7c0fe 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -9,19 +9,10 @@ "ref\087mv02c65y.fsf@xmission.com\0" "ref\01519253867.19593.25.camel@linux.vnet.ibm.com\0" "ref\087r2peaqf0.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 18:32:34 -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 17:12 -0600, Eric W. Biederman wrote:\n" @@ -34,12 +25,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" @@ -47,7 +38,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" @@ -55,7 +46,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" @@ -96,7 +87,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" @@ -109,7 +100,7 @@ "\n" "The information might be there, but IMA currently detects a file\n" "change and resets the flags only when the last writer calls\n" - "__fput(). Any other time, new support would be needed.\n" + "__fput().??Any other time, new support would be needed.\n" "\n" "Mimi\n" "\n" @@ -121,6 +112,11 @@ "> SB_I_IMA_UNVERIFIABLE_SIGNATURES.\n" "> \n" "> Eric\n" - > + "> \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 -d181301a1d031f42545f61d0a6a06527d176d7fadd72d48b8e0ae8b466bbe00e +cec67ec92d37c341c494af7289af62640d4dbbf06ce17a8197a0a59b9b6abee8
diff --git a/a/1.txt b/N2/1.txt index 20ce9ae..1c5f581 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -8,12 +8,12 @@ On Wed, 2018-02-21 at 17:12 -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 @@ -21,7 +21,7 @@ On Wed, 2018-02-21 at 17:12 -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. > >> > @@ -29,7 +29,7 @@ On Wed, 2018-02-21 at 17:12 -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 @@ -70,7 +70,7 @@ On Wed, 2018-02-21 at 17:12 -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. > > As I understand the second scenario SB_I_IMA_UNVERIFIABLE_SIGNATURES > is set, which implies that the filesystem is lacking something for IMA @@ -83,7 +83,7 @@ On Wed, 2018-02-21 at 17:12 -0600, Eric W. Biederman wrote: The information might be there, but IMA currently detects a file change and resets the flags only when the last writer calls -__fput(). Any other time, new support would be needed. +__fput(). Any other time, new support would be needed. Mimi diff --git a/a/content_digest b/N2/content_digest index 691d6bf..6a012ce 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -34,12 +34,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" @@ -47,7 +47,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" @@ -55,7 +55,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" @@ -96,7 +96,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" @@ -109,7 +109,7 @@ "\n" "The information might be there, but IMA currently detects a file\n" "change and resets the flags only when the last writer calls\n" - "__fput(). Any other time, new support would be needed.\n" + "__fput().\302\240\302\240Any other time, new support would be needed.\n" "\n" "Mimi\n" "\n" @@ -123,4 +123,4 @@ "> Eric\n" > -d181301a1d031f42545f61d0a6a06527d176d7fadd72d48b8e0ae8b466bbe00e +f5e267e36fe666cff904b02ce6553e1b83bfe8caf690a4b860646f36a60190ad
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.