diff for duplicates of <877erbr93i.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index e7dddf3..cc91ade 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -33,7 +33,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> >> IMA. >> >> > >> >> > Using s_iflags instead of fs_flags is fine, but I'm not sure how this ->> >> > affects the IMA policy. This patch set assumes only unprivileged, +>> >> > affects the IMA policy. ?This patch set assumes only unprivileged, >> >> > untrusted filesytems can automatically fail file signature >> >> > verification (2nd patch), as that hasn't yet been upstreamed and won't >> >> > break userspace. @@ -72,7 +72,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> sb->s_iflags |= SB_I_NOIMA); >> > >> > SB_I_NOIMA would be really confusing, as we're not disabling IMA in ->> > general, just failing the signature verification. The measurement, +>> > general, just failing the signature verification. ?The measurement, >> > even if it is meaningless, is an indication in the measurement list >> > that the file was accessed/executed. >> > @@ -89,7 +89,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> around. >> > >> > The last patch (4/4) had 1 line, which set the fs_flags ->> > unconditionally in fuse_fs_type. Instead, we can set the sb->s_iflags +>> > unconditionally in fuse_fs_type. ?Instead, we can set the sb->s_iflags >> > in fuse_fill_supper(), again unconditionally, letting IMA-appraisal >> > differentiate between privileged and unprivileged. >> @@ -114,13 +114,13 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> The test should reside in fuse and the IMA code should honor it. > > This would all make a lot of sense if the privileged use case was -> really trusted, but it isn't. We're just not automatically failing +> really trusted, but it isn't. ?We're just not automatically failing > the signature verification, because it "might" break existing > userspace. > > This now puts the burden of knowing which file systems are inherently > not trusted on the IMA custom policy writer, requiring separate per -> file system type or name rules. +> file system type or name rules.? > > The current code first checks to see if the filesystem is untrusted, > before failing the signature verification. So existing generic policy @@ -137,7 +137,7 @@ avoid the wrath of Linus. >> I can also see making decisions like this based on the question are the >> network transfers authenticated aka signed. > -> At least for the time being, remote file systems are untrusted. The +> At least for the time being, remote file systems are untrusted. ?The > main use case for IMA has been in the embedded environment. Then just set SB_I_IMA_UNTRUSTED on all of the remote filesystems. One @@ -155,3 +155,8 @@ is using the feature. This appears to be precisely one of those times. No one cares, so let's code this clean. 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 90965ca..f989cfa 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -7,17 +7,9 @@ "ref\087d114ygfj.fsf@xmission.com\0" "ref\01518814840.5667.242.camel@linux.vnet.ibm.com\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0Re: [RFC PATCH 2/4] ima: fail signature verification on unprivileged & untrusted filesystems\0" + "Subject\0[RFC PATCH 2/4] ima: fail signature verification on unprivileged & untrusted filesystems\0" "Date\0Sat, 17 Feb 2018 08:20:33 -0600\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Cc\0linux-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" "Mimi Zohar <zohar@linux.vnet.ibm.com> writes:\n" @@ -55,7 +47,7 @@ ">> >> >> IMA.\n" ">> >> >\n" ">> >> > Using s_iflags instead of fs_flags is fine, but I'm not sure how this\n" - ">> >> > affects the IMA policy. This patch set assumes only unprivileged,\n" + ">> >> > affects the IMA policy. ?This patch set assumes only unprivileged,\n" ">> >> > untrusted filesytems can automatically fail file signature\n" ">> >> > verification (2nd patch), as that hasn't yet been upstreamed and won't\n" ">> >> > break userspace.\n" @@ -94,7 +86,7 @@ ">> >> \tsb->s_iflags |= SB_I_NOIMA);\n" ">> >\n" ">> > SB_I_NOIMA would be really confusing, as we're not disabling IMA in\n" - ">> > general, just failing the signature verification. The measurement,\n" + ">> > general, just failing the signature verification. ?The measurement,\n" ">> > even if it is meaningless, is an indication in the measurement list\n" ">> > that the file was accessed/executed.\n" ">> >\n" @@ -111,7 +103,7 @@ ">> >> around.\n" ">> >\n" ">> > The last patch (4/4) had 1 line, which set the fs_flags\n" - ">> > unconditionally in fuse_fs_type. Instead, we can set the sb->s_iflags \n" + ">> > unconditionally in fuse_fs_type. ?Instead, we can set the sb->s_iflags \n" ">> > in fuse_fill_supper(), again unconditionally, letting IMA-appraisal\n" ">> > differentiate between privileged and unprivileged.\n" ">> \n" @@ -136,13 +128,13 @@ ">> The test should reside in fuse and the IMA code should honor it.\n" ">\n" "> This would all make a lot of sense if the privileged use case was\n" - "> really trusted, but it isn't. We're just not automatically failing\n" + "> really trusted, but it isn't. ?We're just not automatically failing\n" "> the signature verification, because it \"might\" break existing\n" "> userspace.\n" ">\n" "> This now puts the burden of knowing which file systems are inherently\n" "> not trusted on the IMA custom policy writer, requiring separate per\n" - "> file system type or name rules. \n" + "> file system type or name rules.?\n" ">\n" "> The current code first checks to see if the filesystem is untrusted,\n" "> before failing the signature verification. So existing generic policy\n" @@ -159,7 +151,7 @@ ">> I can also see making decisions like this based on the question are the\n" ">> network transfers authenticated aka signed.\n" ">\n" - "> At least for the time being, remote file systems are untrusted. The\n" + "> At least for the time being, remote file systems are untrusted. ?The\n" "> main use case for IMA has been in the embedded environment.\n" "\n" "Then just set SB_I_IMA_UNTRUSTED on all of the remote filesystems. One\n" @@ -176,6 +168,11 @@ "\n" "No one cares, so let's code this clean.\n" "\n" - Eric + "Eric\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 -f738ae894234bd97c987812e967a04f25df28b1db90b391d3bcf86b2a6257d2a +e588120ec807aed116be559e05e6a474eecb3165fbc62f86a22620b3bd1ab04a
diff --git a/a/1.txt b/N2/1.txt index e7dddf3..3f4dd1b 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -33,7 +33,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> >> IMA. >> >> > >> >> > Using s_iflags instead of fs_flags is fine, but I'm not sure how this ->> >> > affects the IMA policy. This patch set assumes only unprivileged, +>> >> > affects the IMA policy. This patch set assumes only unprivileged, >> >> > untrusted filesytems can automatically fail file signature >> >> > verification (2nd patch), as that hasn't yet been upstreamed and won't >> >> > break userspace. @@ -72,7 +72,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> sb->s_iflags |= SB_I_NOIMA); >> > >> > SB_I_NOIMA would be really confusing, as we're not disabling IMA in ->> > general, just failing the signature verification. The measurement, +>> > general, just failing the signature verification. The measurement, >> > even if it is meaningless, is an indication in the measurement list >> > that the file was accessed/executed. >> > @@ -89,7 +89,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> around. >> > >> > The last patch (4/4) had 1 line, which set the fs_flags ->> > unconditionally in fuse_fs_type. Instead, we can set the sb->s_iflags +>> > unconditionally in fuse_fs_type. Instead, we can set the sb->s_iflags >> > in fuse_fill_supper(), again unconditionally, letting IMA-appraisal >> > differentiate between privileged and unprivileged. >> @@ -114,13 +114,13 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> The test should reside in fuse and the IMA code should honor it. > > This would all make a lot of sense if the privileged use case was -> really trusted, but it isn't. We're just not automatically failing +> really trusted, but it isn't. We're just not automatically failing > the signature verification, because it "might" break existing > userspace. > > This now puts the burden of knowing which file systems are inherently > not trusted on the IMA custom policy writer, requiring separate per -> file system type or name rules. +> file system type or name rules. > > The current code first checks to see if the filesystem is untrusted, > before failing the signature verification. So existing generic policy @@ -137,7 +137,7 @@ avoid the wrath of Linus. >> I can also see making decisions like this based on the question are the >> network transfers authenticated aka signed. > -> At least for the time being, remote file systems are untrusted. The +> At least for the time being, remote file systems are untrusted. The > main use case for IMA has been in the embedded environment. Then just set SB_I_IMA_UNTRUSTED on all of the remote filesystems. One diff --git a/a/content_digest b/N2/content_digest index 90965ca..bb28144 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -55,7 +55,7 @@ ">> >> >> IMA.\n" ">> >> >\n" ">> >> > Using s_iflags instead of fs_flags is fine, but I'm not sure how this\n" - ">> >> > affects the IMA policy. This patch set assumes only unprivileged,\n" + ">> >> > affects the IMA policy. \302\240This patch set assumes only unprivileged,\n" ">> >> > untrusted filesytems can automatically fail file signature\n" ">> >> > verification (2nd patch), as that hasn't yet been upstreamed and won't\n" ">> >> > break userspace.\n" @@ -94,7 +94,7 @@ ">> >> \tsb->s_iflags |= SB_I_NOIMA);\n" ">> >\n" ">> > SB_I_NOIMA would be really confusing, as we're not disabling IMA in\n" - ">> > general, just failing the signature verification. The measurement,\n" + ">> > general, just failing the signature verification. \302\240The measurement,\n" ">> > even if it is meaningless, is an indication in the measurement list\n" ">> > that the file was accessed/executed.\n" ">> >\n" @@ -111,7 +111,7 @@ ">> >> around.\n" ">> >\n" ">> > The last patch (4/4) had 1 line, which set the fs_flags\n" - ">> > unconditionally in fuse_fs_type. Instead, we can set the sb->s_iflags \n" + ">> > unconditionally in fuse_fs_type. \302\240Instead, we can set the sb->s_iflags \n" ">> > in fuse_fill_supper(), again unconditionally, letting IMA-appraisal\n" ">> > differentiate between privileged and unprivileged.\n" ">> \n" @@ -136,13 +136,13 @@ ">> The test should reside in fuse and the IMA code should honor it.\n" ">\n" "> This would all make a lot of sense if the privileged use case was\n" - "> really trusted, but it isn't. We're just not automatically failing\n" + "> really trusted, but it isn't. \302\240We're just not automatically failing\n" "> the signature verification, because it \"might\" break existing\n" "> userspace.\n" ">\n" "> This now puts the burden of knowing which file systems are inherently\n" "> not trusted on the IMA custom policy writer, requiring separate per\n" - "> file system type or name rules. \n" + "> file system type or name rules.\302\240\n" ">\n" "> The current code first checks to see if the filesystem is untrusted,\n" "> before failing the signature verification. So existing generic policy\n" @@ -159,7 +159,7 @@ ">> I can also see making decisions like this based on the question are the\n" ">> network transfers authenticated aka signed.\n" ">\n" - "> At least for the time being, remote file systems are untrusted. The\n" + "> At least for the time being, remote file systems are untrusted. \302\240The\n" "> main use case for IMA has been in the embedded environment.\n" "\n" "Then just set SB_I_IMA_UNTRUSTED on all of the remote filesystems. One\n" @@ -178,4 +178,4 @@ "\n" Eric -f738ae894234bd97c987812e967a04f25df28b1db90b391d3bcf86b2a6257d2a +2bafca2869fec3fa7bdacfa20893782ab868dc7eb0527ebd4c7818bc6afd2d88
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.