diff for duplicates of <1500058090.3583.28.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 258bc06..204e57f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,17 +1,17 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: -> 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 @@ -28,7 +28,7 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: > > 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 @@ -39,27 +39,22 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: If I'm understanding the discussion correctly, this isn't an issue for layered copy on write filesystems, as each fs layer could have it's -own set of xattrs. ?The underlying and layered xattrs should be able -to co-exist. ?Use the layered xattr if it exists, but fall back to +own set of xattrs. The underlying and layered xattrs should be able +to co-exist. Use the layered xattr if it exists, but fall back to using the underlying xattr if it doesn't. -The concern is with a shared filesystems. ?In that case, for IMA it -would make sense to support a native and a namespace xattr. ?If due to +The concern is with a shared filesystems. In that case, for IMA it +would make sense to support a native and a namespace xattr. If due to xattr space limitations we have to limit the number of xattrs, then we should limit it to two - a native and a namespace version, with a "uid=" tag - first namespace gets permission to write the namespace -xattr. ?Again, like in the layered case, if the namespace xattr +xattr. Again, like in the layered case, if the namespace xattr doesn't exist, fall back to using the native xattr. This allows most files to use the underlying xattrs, but allows a few -files to be re-signed inside the namespace, as needed. ?For the +files to be re-signed inside the namespace, as needed. For the layered filesystem case, this would allow mutable file hashes to be -written. ?(Unclear as to how shared filesystems would work in this +written. (Unclear as to how shared filesystems would work in this case.) 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 8a02032..236d293 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,34 +1,24 @@ - "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" - "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" - "Subject\0[PATCH v2] xattr: Enable security.capability in user namespaces\0" + "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" + "Subject\0Re: [PATCH v2] xattr: Enable security.capability in user namespaces\0" "Date\0Fri, 14 Jul 2017 14:48:10 -0400\0" - "To\0linux-security-module@vger.kernel.org\0" - "\00:1\0" + "To\0lkp@lists.01.org\0" + "\01:1\0" "b\0" "On Fri, 2017-07-14 at 12:35 -0500, 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/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" @@ -45,7 +35,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" @@ -56,29 +46,24 @@ "\n" "If I'm understanding the discussion correctly, this isn't an issue for\n" "layered copy on write filesystems, as each fs layer could have it's\n" - "own set of xattrs. ?The underlying and layered xattrs should be able\n" - "to co-exist. ?Use the layered xattr if it exists, but fall back to\n" + "own set of xattrs. \302\240The underlying and layered xattrs should be able\n" + "to co-exist. \302\240Use the layered xattr if it exists, but fall back to\n" "using the underlying xattr if it doesn't.\n" "\n" - "The concern is with a shared filesystems. ?In that case, for IMA it\n" - "would make sense to support a native and a namespace xattr. ?If due to\n" + "The concern is with a shared filesystems. \302\240In that case, for IMA it\n" + "would make sense to support a native and a namespace xattr. \302\240If due to\n" "xattr space limitations we have to limit the number of xattrs, then we\n" "should limit it to two - a native and a namespace version, with a\n" "\"uid=\" tag - first namespace gets permission to write the namespace\n" - "xattr. ?Again, like in the layered case, if the namespace xattr\n" + "xattr. \302\240Again, like in the layered case, if the namespace xattr\n" "doesn't exist, fall back to using the native xattr.\n" "\n" "This allows most files to use the underlying xattrs, but allows a few\n" - "files to be re-signed inside the namespace, as needed. ?For the\n" + "files to be re-signed inside the namespace, as needed. \302\240For the\n" "layered filesystem case, this would allow mutable file hashes to be\n" - "written. ?(Unclear as to how shared filesystems would work in this\n" + "written. \302\240(Unclear as to how shared filesystems would work in this\n" "case.)\n" "\n" - "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 + Mimi -bc25d99dba4460191bbce4b7e69b12a31b3c8177a85767744dd62c7930c3f403 +2537c9e2e90c54ff8338f81ab426da542383a8e53a9ce803d3a1dfbb4be52b9b
diff --git a/a/1.txt b/N2/1.txt index 258bc06..a4c95ab 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,17 +1,17 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: -> 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 @@ -28,7 +28,7 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: > > 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 @@ -39,27 +39,22 @@ On Fri, 2017-07-14 at 12:35 -0500, Serge E. Hallyn wrote: If I'm understanding the discussion correctly, this isn't an issue for layered copy on write filesystems, as each fs layer could have it's -own set of xattrs. ?The underlying and layered xattrs should be able -to co-exist. ?Use the layered xattr if it exists, but fall back to +own set of xattrs. The underlying and layered xattrs should be able +to co-exist. Use the layered xattr if it exists, but fall back to using the underlying xattr if it doesn't. -The concern is with a shared filesystems. ?In that case, for IMA it -would make sense to support a native and a namespace xattr. ?If due to +The concern is with a shared filesystems. In that case, for IMA it +would make sense to support a native and a namespace xattr. If due to xattr space limitations we have to limit the number of xattrs, then we should limit it to two - a native and a namespace version, with a "uid=" tag - first namespace gets permission to write the namespace -xattr. ?Again, like in the layered case, if the namespace xattr +xattr. Again, like in the layered case, if the namespace xattr doesn't exist, fall back to using the native xattr. This allows most files to use the underlying xattrs, but allows a few -files to be re-signed inside the namespace, as needed. ?For the +files to be re-signed inside the namespace, as needed. For the layered filesystem case, this would allow mutable file hashes to be -written. ?(Unclear as to how shared filesystems would work in this +written. (Unclear as to how shared filesystems would work in this case.) 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/N2/content_digest index 8a02032..c8831e7 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -9,26 +9,40 @@ "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" - "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" - "Subject\0[PATCH v2] xattr: Enable security.capability in user namespaces\0" + "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" + "Subject\0Re: [PATCH v2] xattr: Enable security.capability in user namespaces\0" "Date\0Fri, 14 Jul 2017 14:48:10 -0400\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0Serge E. Hallyn <serge@hallyn.com>" + Stefan Berger <stefanb@linux.vnet.ibm.com> + " Mimi Zohar <zohar@us.ibm.com>\0" + "Cc\0Eric W. Biederman <ebiederm@xmission.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" "On Fri, 2017-07-14 at 12:35 -0500, 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/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" @@ -45,7 +59,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" @@ -56,29 +70,24 @@ "\n" "If I'm understanding the discussion correctly, this isn't an issue for\n" "layered copy on write filesystems, as each fs layer could have it's\n" - "own set of xattrs. ?The underlying and layered xattrs should be able\n" - "to co-exist. ?Use the layered xattr if it exists, but fall back to\n" + "own set of xattrs. \302\240The underlying and layered xattrs should be able\n" + "to co-exist. \302\240Use the layered xattr if it exists, but fall back to\n" "using the underlying xattr if it doesn't.\n" "\n" - "The concern is with a shared filesystems. ?In that case, for IMA it\n" - "would make sense to support a native and a namespace xattr. ?If due to\n" + "The concern is with a shared filesystems. \302\240In that case, for IMA it\n" + "would make sense to support a native and a namespace xattr. \302\240If due to\n" "xattr space limitations we have to limit the number of xattrs, then we\n" "should limit it to two - a native and a namespace version, with a\n" "\"uid=\" tag - first namespace gets permission to write the namespace\n" - "xattr. ?Again, like in the layered case, if the namespace xattr\n" + "xattr. \302\240Again, like in the layered case, if the namespace xattr\n" "doesn't exist, fall back to using the native xattr.\n" "\n" "This allows most files to use the underlying xattrs, but allows a few\n" - "files to be re-signed inside the namespace, as needed. ?For the\n" + "files to be re-signed inside the namespace, as needed. \302\240For the\n" "layered filesystem case, this would allow mutable file hashes to be\n" - "written. ?(Unclear as to how shared filesystems would work in this\n" + "written. \302\240(Unclear as to how shared filesystems would work in this\n" "case.)\n" "\n" - "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 + Mimi -bc25d99dba4460191bbce4b7e69b12a31b3c8177a85767744dd62c7930c3f403 +10945995553f992dfdbcdc120a6f40ada7771087fc6d027fedd8bc0217a3f1f6
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.