diff for duplicates of <87379yshhv.fsf@xmission.com> diff --git a/a/1.txt b/N1/1.txt index 9b9c141..3277e1e 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -5,12 +5,12 @@ James Bottomley <James.Bottomley@HansenPartnership.com> writes: >> > >> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: >> > > ->> > > The concern is with a shared filesystems. ?In that case, for IMA +>> > > 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 +>> > > 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 +>> > > write the namespace xattr. Again, like in the layered case, if >> > > the namespace xattr doesn't exist, fall back to using the native >> > > xattr. >> > @@ -24,13 +24,13 @@ James Bottomley <James.Bottomley@HansenPartnership.com> writes: >> > shared filesystems (like NFS) as well as containerised bind mounts. >> >> Writing security.ima requires being root with CAP_SYS_ADMIN ->> privileges. ?I wouldn't want to give root within the namespace +>> privileges. I wouldn't want to give root within the namespace >> permission to over write or just extend the native security.ima. > -> but why? ?That's partly the point of all of this: some security. +> but why? That's partly the point of all of this: some security. > attributes can't be written by container root without some supervision > (the capability ones are the hugely problematic ones from this point of -> view), but for some there's no reason they shouldn't be. ?What would be +> view), but for some there's no reason they shouldn't be. What would be > the reason that root in a container shouldn't be able to write the ima > xattr the same as host root could on its filesystem? @@ -45,8 +45,3 @@ So I don't actually see any disagreement here except perhaps for terminology. 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 36bfeb4..f2cf45c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,23 +1,9 @@ - "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\01500058090.3583.28.camel@linux.vnet.ibm.com\0" - "ref\01500058362.2853.28.camel@HansenPartnership.com\0" - "ref\01500062619.3583.71.camel@linux.vnet.ibm.com\0" "ref\01500064799.2853.36.camel@HansenPartnership.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 18:53:16 -0500\0" - "To\0linux-security-module@vger.kernel.org\0" - "\00:1\0" + "To\0lkp@lists.01.org\0" + "\01:1\0" "b\0" "James Bottomley <James.Bottomley@HansenPartnership.com> writes:\n" "\n" @@ -26,12 +12,12 @@ ">> > \n" ">> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:\n" ">> > > \n" - ">> > > The concern is with a shared filesystems. ?In that case, for IMA\n" + ">> > > The concern is with a shared filesystems. \302\240In that case, for IMA\n" ">> > > it would make sense to support a native and a namespace xattr.\n" - ">> > > ?If due to xattr space limitations we have to limit the number of\n" + ">> > > \302\240If due to xattr space limitations we have to limit the number of\n" ">> > > xattrs, then we should limit it to two - a native and a namespace\n" ">> > > version, with a \"uid=\" tag - first namespace gets permission to\n" - ">> > > write the namespace xattr. ?Again, like in the layered case, if\n" + ">> > > write the namespace xattr. \302\240Again, like in the layered case, if\n" ">> > > the namespace xattr doesn't exist, fall back to using the native\n" ">> > > xattr.\n" ">> > \n" @@ -45,13 +31,13 @@ ">> > shared filesystems (like NFS) as well as containerised bind mounts.\n" ">> \n" ">> Writing security.ima requires being root with CAP_SYS_ADMIN\n" - ">> privileges. ?I wouldn't want to give root within the namespace\n" + ">> privileges. \302\240I wouldn't want to give root within the namespace\n" ">> permission to over write or just extend the native security.ima.\n" ">\n" - "> but why? ?That's partly the point of all of this: some security.\n" + "> but why? \302\240That's partly the point of all of this: some security.\n" "> attributes can't be written by container root without some supervision\n" "> (the capability ones are the hugely problematic ones from this point of\n" - "> view), but for some there's no reason they shouldn't be. ?What would be\n" + "> view), but for some there's no reason they shouldn't be. \302\240What would be\n" "> the reason that root in a container shouldn't be able to write the ima\n" "> xattr the same as host root could on its filesystem?\n" "\n" @@ -65,11 +51,6 @@ "So I don't actually see any disagreement here except perhaps for\n" "terminology.\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 -a17fb2cb23b847eb44f45f9daeaa77d8db01cc69ea02c9c3be8a729e52defd69 +8efa6fe688d448a0d6f2de18389463c729a7c287c25c7ba0ac927a7ffad9372e
diff --git a/a/1.txt b/N2/1.txt index 9b9c141..3277e1e 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -5,12 +5,12 @@ James Bottomley <James.Bottomley@HansenPartnership.com> writes: >> > >> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: >> > > ->> > > The concern is with a shared filesystems. ?In that case, for IMA +>> > > 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 +>> > > 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 +>> > > write the namespace xattr. Again, like in the layered case, if >> > > the namespace xattr doesn't exist, fall back to using the native >> > > xattr. >> > @@ -24,13 +24,13 @@ James Bottomley <James.Bottomley@HansenPartnership.com> writes: >> > shared filesystems (like NFS) as well as containerised bind mounts. >> >> Writing security.ima requires being root with CAP_SYS_ADMIN ->> privileges. ?I wouldn't want to give root within the namespace +>> privileges. I wouldn't want to give root within the namespace >> permission to over write or just extend the native security.ima. > -> but why? ?That's partly the point of all of this: some security. +> but why? That's partly the point of all of this: some security. > attributes can't be written by container root without some supervision > (the capability ones are the hugely problematic ones from this point of -> view), but for some there's no reason they shouldn't be. ?What would be +> view), but for some there's no reason they shouldn't be. What would be > the reason that root in a container shouldn't be able to write the ima > xattr the same as host root could on its filesystem? @@ -45,8 +45,3 @@ So I don't actually see any disagreement here except perhaps for terminology. 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 36bfeb4..1b561eb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -14,9 +14,19 @@ "ref\01500062619.3583.71.camel@linux.vnet.ibm.com\0" "ref\01500064799.2853.36.camel@HansenPartnership.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 18:53:16 -0500\0" - "To\0linux-security-module@vger.kernel.org\0" + "To\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" + "Cc\0Mimi Zohar <zohar@linux.vnet.ibm.com>" + Serge E. Hallyn <serge@hallyn.com> + Stefan Berger <stefanb@linux.vnet.ibm.com> + Mimi Zohar <zohar@us.ibm.com> + containers@lists.linux-foundation.org + linux-kernel@vger.kernel.org + linux-security-module@vger.kernel.org + casey@schaufler-ca.com + Theodore Ts'o <tytso@mit.edu> + " lkp@01.org\0" "\00:1\0" "b\0" "James Bottomley <James.Bottomley@HansenPartnership.com> writes:\n" @@ -26,12 +36,12 @@ ">> > \n" ">> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:\n" ">> > > \n" - ">> > > The concern is with a shared filesystems. ?In that case, for IMA\n" + ">> > > The concern is with a shared filesystems. \302\240In that case, for IMA\n" ">> > > it would make sense to support a native and a namespace xattr.\n" - ">> > > ?If due to xattr space limitations we have to limit the number of\n" + ">> > > \302\240If due to xattr space limitations we have to limit the number of\n" ">> > > xattrs, then we should limit it to two - a native and a namespace\n" ">> > > version, with a \"uid=\" tag - first namespace gets permission to\n" - ">> > > write the namespace xattr. ?Again, like in the layered case, if\n" + ">> > > write the namespace xattr. \302\240Again, like in the layered case, if\n" ">> > > the namespace xattr doesn't exist, fall back to using the native\n" ">> > > xattr.\n" ">> > \n" @@ -45,13 +55,13 @@ ">> > shared filesystems (like NFS) as well as containerised bind mounts.\n" ">> \n" ">> Writing security.ima requires being root with CAP_SYS_ADMIN\n" - ">> privileges. ?I wouldn't want to give root within the namespace\n" + ">> privileges. \302\240I wouldn't want to give root within the namespace\n" ">> permission to over write or just extend the native security.ima.\n" ">\n" - "> but why? ?That's partly the point of all of this: some security.\n" + "> but why? \302\240That's partly the point of all of this: some security.\n" "> attributes can't be written by container root without some supervision\n" "> (the capability ones are the hugely problematic ones from this point of\n" - "> view), but for some there's no reason they shouldn't be. ?What would be\n" + "> view), but for some there's no reason they shouldn't be. \302\240What would be\n" "> the reason that root in a container shouldn't be able to write the ima\n" "> xattr the same as host root could on its filesystem?\n" "\n" @@ -65,11 +75,6 @@ "So I don't actually see any disagreement here except perhaps for\n" "terminology.\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 -a17fb2cb23b847eb44f45f9daeaa77d8db01cc69ea02c9c3be8a729e52defd69 +ebce64649e0f0ebd891f01be9feddf276663407e3cfb839749dcec8dd83543bf
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.