diff for duplicates of <871spir2hp.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index 2cb4adf..843f5b4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,19 +3,19 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote: >> "Serge E. Hallyn" <serge@hallyn.com> writes: >> ->> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): +>> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com): >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: ->> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): +>> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com): >> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes: >> >> >>> >> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: >> >> >>>> >> >> >>>>>My big question right now is can you implement Ted's suggested ->> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ? +>> >> >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ? >> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. >> >> >>>> ->> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)? +>> >> >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)? >> >> >>>> >> >> >>>The latter. >> >> >>That case would prevent a container user from overriding the xattr @@ -32,7 +32,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> need to get rid of security.ima first, possibly by copying each >> >> file, deleting the original file, and renaming the copied file to >> >> the original name, or should I just be able to write out a new ->> >> signature, thus creating security.ima at uid=1000 besides the +>> >> signature, thus creating security.ima(a)uid=1000 besides the >> >> security.ima ? >> >> >> >> Stefan @@ -55,7 +55,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > xattrs and other file metadata. (file meta-data) > > The same rules would apply to security.evm, as described in my -> response. ?Based on it's view of the security xattrs, either the +> response. Based on it's view of the security xattrs, either the > native or namespace security.evm would be updated. > >> If there is an attribute with a simple file hash I think it only make @@ -63,8 +63,8 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> multiples. > > Only files that are in the IMA-appraisal policy is the file hash -> calculated and written out as security.ima. ?Depending this policy, -> does the security.ima exist. ?So if the file is in policy for both the +> calculated and written out as security.ima. Depending this policy, +> does the security.ima exist. So if the file is in policy for both the > native and namespace policies, agreed the same hash doesn't need to be > written as two different xattrs. > @@ -103,7 +103,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> evm content. > > We need to resolve the xattr issue in order to namespace IMA- -> appraisal.? +> appraisal. Mimi I have two questions: @@ -122,8 +122,3 @@ live with the native policy taking precedence over the container policy then we have a solution to the IMA xattrs. 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 c25dee6..f495e9e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,40 +1,28 @@ - "ref\087y3rscz9j.fsf@xmission.com\0" - "ref\020170713164012.brj2flnkaaks2oci@thunk.org\0" - "ref\087k23cb6os.fsf@xmission.com\0" - "ref\0847ccb2a-30c0-a94c-df6f-091c8901eaa0@linux.vnet.ibm.com\0" - "ref\087bmoo8bxb.fsf@xmission.com\0" - "ref\09a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com\0" - "ref\087h8yf7szd.fsf@xmission.com\0" - "ref\065dbe654-0d99-03fa-c838-5a726b462826@linux.vnet.ibm.com\0" - "ref\020170714133437.GA16737@mail.hallyn.com\0" - "ref\0596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com\0" - "ref\020170714173556.GA19669@mail.hallyn.com\0" - "ref\0xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com\0" "ref\01500060374.3583.57.camel@linux.vnet.ibm.com\0" - "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0[PATCH v2] xattr: Enable security.capability in user namespaces\0" + "From\0Eric W. Biederman <ebiederm@xmission.com>\0" + "Subject\0Re: [PATCH v2] xattr: Enable security.capability in user namespaces\0" "Date\0Fri, 14 Jul 2017 19:02:42 -0500\0" - "To\0linux-security-module@vger.kernel.org\0" - "\00:1\0" + "To\0lkp@lists.01.org\0" + "\01:1\0" "b\0" "Mimi Zohar <zohar@linux.vnet.ibm.com> writes:\n" "\n" "> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:\n" ">> \"Serge E. Hallyn\" <serge@hallyn.com> writes:\n" ">> \n" - ">> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n" + ">> > Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):\n" ">> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:\n" - ">> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n" + ">> >> >Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):\n" ">> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:\n" ">> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:\n" ">> >> >>>\n" ">> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:\n" ">> >> >>>>\n" ">> >> >>>>>My big question right now is can you implement Ted's suggested\n" - ">> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?\n" + ">> >> >>>>>restriction. Only one security.foo or secuirty.foo(a)... attribute ?\n" ">> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.\n" ">> >> >>>>\n" - ">> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?\n" + ">> >> >>>>So now you want to allow security.foo and one security.foo(a)uid=<> or just a single one security.foo(@[[:print:]]*)?\n" ">> >> >>>>\n" ">> >> >>>The latter.\n" ">> >> >>That case would prevent a container user from overriding the xattr\n" @@ -51,7 +39,7 @@ ">> >> need to get rid of security.ima first, possibly by copying each\n" ">> >> file, deleting the original file, and renaming the copied file to\n" ">> >> the original name, or should I just be able to write out a new\n" - ">> >> signature, thus creating security.ima at uid=1000 besides the\n" + ">> >> signature, thus creating security.ima(a)uid=1000 besides the\n" ">> >> security.ima ?\n" ">> >> \n" ">> >> Stefan\n" @@ -74,7 +62,7 @@ "> xattrs and other file metadata. (file meta-data)\n" ">\n" "> The same rules would apply to security.evm, as described in my\n" - "> response. ?Based on it's view of the security xattrs, either the\n" + "> response. \302\240Based on it's view of the security xattrs, either the\n" "> native or namespace security.evm would be updated.\n" ">\n" ">> If there is an attribute with a simple file hash I think it only make\n" @@ -82,8 +70,8 @@ ">> multiples.\n" ">\n" "> Only files that are in the IMA-appraisal policy is the file hash\n" - "> calculated and written out as security.ima. ?Depending this policy,\n" - "> does the security.ima exist. ?So if the file is in policy for both the\n" + "> calculated and written out as security.ima. \302\240Depending this policy,\n" + "> does the security.ima exist. \302\240So if the file is in policy for both the\n" "> native and namespace policies, agreed the same hash doesn't need to be\n" "> written as two different xattrs.\n" ">\n" @@ -122,7 +110,7 @@ ">> evm content.\n" ">\n" "> We need to resolve the xattr issue in order to namespace IMA-\n" - "> appraisal.?\n" + "> appraisal.\302\240\n" "\n" "\n" "Mimi I have two questions:\n" @@ -140,11 +128,6 @@ "live with the native policy taking precedence over the container policy\n" "then we have a solution to the IMA xattrs.\n" "\n" - "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 + Eric -46456b2ef4dfd28091a3189170afbd244566ca0375bdca1d396def12b462f1aa +5d93efab66dc158e787c0ed01b9e4400a9bd2723b5b854c0b02c3d7c417995ee
diff --git a/a/1.txt b/N2/1.txt index 2cb4adf..a154346 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -3,19 +3,19 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote: >> "Serge E. Hallyn" <serge@hallyn.com> writes: >> ->> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): +>> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: ->> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): +>> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes: >> >> >>> >> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote: >> >> >>>> >> >> >>>>>My big question right now is can you implement Ted's suggested ->> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ? +>> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ? >> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done. >> >> >>>> ->> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)? +>> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)? >> >> >>>> >> >> >>>The latter. >> >> >>That case would prevent a container user from overriding the xattr @@ -32,7 +32,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> >> need to get rid of security.ima first, possibly by copying each >> >> file, deleting the original file, and renaming the copied file to >> >> the original name, or should I just be able to write out a new ->> >> signature, thus creating security.ima at uid=1000 besides the +>> >> signature, thus creating security.ima@uid=1000 besides the >> >> security.ima ? >> >> >> >> Stefan @@ -55,7 +55,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: > xattrs and other file metadata. (file meta-data) > > The same rules would apply to security.evm, as described in my -> response. ?Based on it's view of the security xattrs, either the +> response. Based on it's view of the security xattrs, either the > native or namespace security.evm would be updated. > >> If there is an attribute with a simple file hash I think it only make @@ -63,8 +63,8 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> multiples. > > Only files that are in the IMA-appraisal policy is the file hash -> calculated and written out as security.ima. ?Depending this policy, -> does the security.ima exist. ?So if the file is in policy for both the +> calculated and written out as security.ima. Depending this policy, +> does the security.ima exist. So if the file is in policy for both the > native and namespace policies, agreed the same hash doesn't need to be > written as two different xattrs. > @@ -103,7 +103,7 @@ Mimi Zohar <zohar@linux.vnet.ibm.com> writes: >> evm content. > > We need to resolve the xattr issue in order to namespace IMA- -> appraisal.? +> appraisal. Mimi I have two questions: @@ -122,8 +122,3 @@ live with the native policy taking precedence over the container policy then we have a solution to the IMA xattrs. 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/N2/content_digest index c25dee6..502524c 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -12,9 +12,23 @@ "ref\0xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com\0" "ref\01500060374.3583.57.camel@linux.vnet.ibm.com\0" "From\0ebiederm@xmission.com (Eric W. Biederman)\0" - "Subject\0[PATCH v2] xattr: Enable security.capability in user namespaces\0" + "Subject\0Re: [PATCH v2] xattr: Enable security.capability in user namespaces\0" "Date\0Fri, 14 Jul 2017 19:02:42 -0500\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" + "Cc\0Serge E. Hallyn <serge@hallyn.com>" + Stefan Berger <stefanb@linux.vnet.ibm.com> + Mimi Zohar <zohar@us.ibm.com> + Theodore Ts'o <tytso@mit.edu> + containers@lists.linux-foundation.org + lkp@01.org + linux-kernel@vger.kernel.org + tycho@docker.com + James.Bottomley@hansenpartnership.com + vgoyal@redhat.com + christian.brauner@mailbox.org + amir73il@gmail.com + linux-security-module@vger.kernel.org + " casey@schaufler-ca.com\0" "\00:1\0" "b\0" "Mimi Zohar <zohar@linux.vnet.ibm.com> writes:\n" @@ -22,19 +36,19 @@ "> On Fri, 2017-07-14 at 13:17 -0500, Eric W. Biederman wrote:\n" ">> \"Serge E. Hallyn\" <serge@hallyn.com> writes:\n" ">> \n" - ">> > Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n" + ">> > Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n" ">> >> On 07/14/2017 09:34 AM, Serge E. Hallyn wrote:\n" - ">> >> >Quoting Stefan Berger (stefanb at linux.vnet.ibm.com):\n" + ">> >> >Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n" ">> >> >>On 07/13/2017 08:38 PM, Eric W. Biederman wrote:\n" ">> >> >>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:\n" ">> >> >>>\n" ">> >> >>>>On 07/13/2017 01:49 PM, Eric W. Biederman wrote:\n" ">> >> >>>>\n" ">> >> >>>>>My big question right now is can you implement Ted's suggested\n" - ">> >> >>>>>restriction. Only one security.foo or secuirty.foo at ... attribute ?\n" + ">> >> >>>>>restriction. Only one security.foo or secuirty.foo@... attribute ?\n" ">> >> >>>>We need to raw-list the xattrs and do the check before writing them. I am fairly sure this can be done.\n" ">> >> >>>>\n" - ">> >> >>>>So now you want to allow security.foo and one security.foo at uid=<> or just a single one security.foo(@[[:print:]]*)?\n" + ">> >> >>>>So now you want to allow security.foo and one security.foo@uid=<> or just a single one security.foo(@[[:print:]]*)?\n" ">> >> >>>>\n" ">> >> >>>The latter.\n" ">> >> >>That case would prevent a container user from overriding the xattr\n" @@ -51,7 +65,7 @@ ">> >> need to get rid of security.ima first, possibly by copying each\n" ">> >> file, deleting the original file, and renaming the copied file to\n" ">> >> the original name, or should I just be able to write out a new\n" - ">> >> signature, thus creating security.ima at uid=1000 besides the\n" + ">> >> signature, thus creating security.ima@uid=1000 besides the\n" ">> >> security.ima ?\n" ">> >> \n" ">> >> Stefan\n" @@ -74,7 +88,7 @@ "> xattrs and other file metadata. (file meta-data)\n" ">\n" "> The same rules would apply to security.evm, as described in my\n" - "> response. ?Based on it's view of the security xattrs, either the\n" + "> response. \302\240Based on it's view of the security xattrs, either the\n" "> native or namespace security.evm would be updated.\n" ">\n" ">> If there is an attribute with a simple file hash I think it only make\n" @@ -82,8 +96,8 @@ ">> multiples.\n" ">\n" "> Only files that are in the IMA-appraisal policy is the file hash\n" - "> calculated and written out as security.ima. ?Depending this policy,\n" - "> does the security.ima exist. ?So if the file is in policy for both the\n" + "> calculated and written out as security.ima. \302\240Depending this policy,\n" + "> does the security.ima exist. \302\240So if the file is in policy for both the\n" "> native and namespace policies, agreed the same hash doesn't need to be\n" "> written as two different xattrs.\n" ">\n" @@ -122,7 +136,7 @@ ">> evm content.\n" ">\n" "> We need to resolve the xattr issue in order to namespace IMA-\n" - "> appraisal.?\n" + "> appraisal.\302\240\n" "\n" "\n" "Mimi I have two questions:\n" @@ -140,11 +154,6 @@ "live with the native policy taking precedence over the container policy\n" "then we have a solution to the IMA xattrs.\n" "\n" - "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 + Eric -46456b2ef4dfd28091a3189170afbd244566ca0375bdca1d396def12b462f1aa +19b0e2ee3995d41ab2ba6d306c55c956a14b1552f3c3d84ed63db96f42920d2e
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.