diff for duplicates of <1519224379.3736.154.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index e2e34af..cbd3942 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,12 +2,12 @@ > > > 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 @@ -15,7 +15,7 @@ > 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. @@ -23,7 +23,7 @@ flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES and SB_I_UNTRUSTED_MOUNTER (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 @@ -39,3 +39,8 @@ Enabled by specifying "ima_policy=unverifiable_sigs" on the boot command line. 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 cf5bebd..5118760 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -5,31 +5,22 @@ "ref\087tvucifji.fsf@xmission.com\0" "ref\01519135329.3736.88.camel@linux.vnet.ibm.com\0" "ref\020180220201636.GA1565@mail.hallyn.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 09:46:19 -0500\0" - "To\0Serge E. Hallyn <serge@hallyn.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>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "> > > On the flip side when it really is a trusted mounter, and it is in a\n" "> > > 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" @@ -37,7 +28,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" @@ -45,7 +36,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" @@ -60,6 +51,11 @@ "Enabled by specifying \"ima_policy=unverifiable_sigs\" on the boot\n" "command line.\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 -c05ad28480d41c677e48dd63c16f2bd311b4e56c917022f4d89cea0482242f55 +53ce2a21a3c8b34f96bd54903228e856adc388b33b4f9596368abbba361bb776
diff --git a/a/1.txt b/N2/1.txt index e2e34af..1462d82 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -2,12 +2,12 @@ > > > 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 @@ -15,7 +15,7 @@ > 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. @@ -23,7 +23,7 @@ flags: SB_I_IMA_UNVERIFIABLE_SIGNATURES and SB_I_UNTRUSTED_MOUNTER (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 cf5bebd..153da88 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -24,12 +24,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" @@ -37,7 +37,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" @@ -45,7 +45,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" @@ -62,4 +62,4 @@ "\n" Mimi -c05ad28480d41c677e48dd63c16f2bd311b4e56c917022f4d89cea0482242f55 +d38727bedf03b32df30c519172abd3e174cd70afedfe18aecd7559215ca6ab8c
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.