From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751184AbdGNUkI (ORCPT ); Fri, 14 Jul 2017 16:40:08 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:44530 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751118AbdGNUkE (ORCPT ); Fri, 14 Jul 2017 16:40:04 -0400 Message-ID: <1500064799.2853.36.camel@HansenPartnership.com> Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces From: James Bottomley To: Mimi Zohar , "Serge E. Hallyn" , Stefan Berger , Mimi Zohar Cc: containers@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, "Eric W. Biederman" , casey@schaufler-ca.com, "Theodore Ts'o" , lkp@01.org Date: Fri, 14 Jul 2017 13:39:59 -0700 In-Reply-To: <1500062619.3583.71.camel@linux.vnet.ibm.com> References: <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <87k23cb6os.fsf@xmission.com> <847ccb2a-30c0-a94c-df6f-091c8901eaa0@linux.vnet.ibm.com> <87bmoo8bxb.fsf@xmission.com> <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com> <87h8yf7szd.fsf@xmission.com> <65dbe654-0d99-03fa-c838-5a726b462826@linux.vnet.ibm.com> <20170714133437.GA16737@mail.hallyn.com> <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> <20170714173556.GA19669@mail.hallyn.com> <1500058090.3583.28.camel@linux.vnet.ibm.com> <1500058362.2853.28.camel@HansenPartnership.com> <1500062619.3583.71.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote: > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote: > > > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: > > > > > > 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 doesn't exist, fall back to using the native > > > xattr. > > > > Just on this point: if we're really concerned about the need on > > shared filesystems to have multiple IMA signatures per file, might > > it not make sense simply to support multiple signatures within the > > security.ima xattr? The rules for writing signature updates within > > user namespaces would be somewhat complex (say only able to replace > > a signature for which you demonstrate you possess the key) but it > > would lead to an implementation which would work for traditional > > 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 > permission to over write or just extend the native security.ima. 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 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? James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James.Bottomley@HansenPartnership.com (James Bottomley) Date: Fri, 14 Jul 2017 13:39:59 -0700 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: <1500062619.3583.71.camel@linux.vnet.ibm.com> References: <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <87k23cb6os.fsf@xmission.com> <847ccb2a-30c0-a94c-df6f-091c8901eaa0@linux.vnet.ibm.com> <87bmoo8bxb.fsf@xmission.com> <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e@linux.vnet.ibm.com> <87h8yf7szd.fsf@xmission.com> <65dbe654-0d99-03fa-c838-5a726b462826@linux.vnet.ibm.com> <20170714133437.GA16737@mail.hallyn.com> <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> <20170714173556.GA19669@mail.hallyn.com> <1500058090.3583.28.camel@linux.vnet.ibm.com> <1500058362.2853.28.camel@HansenPartnership.com> <1500062619.3583.71.camel@linux.vnet.ibm.com> Message-ID: <1500064799.2853.36.camel@HansenPartnership.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote: > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote: > > > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: > > > > > > 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 doesn't exist, fall back to using the native > > > xattr. > > > > Just on this point: if we're really concerned about the need on > > shared filesystems to have multiple IMA signatures per file, might > > it not make sense simply to support multiple signatures within the > > security.ima xattr? The rules for writing signature updates within > > user namespaces would be somewhat complex (say only able to replace > > a signature for which you demonstrate you possess the key) but it > > would lead to an implementation which would work for traditional > > 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 > permission to over write or just extend the native security.ima. 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 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? James -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============6537097551690675334==" MIME-Version: 1.0 From: James Bottomley To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Fri, 14 Jul 2017 13:39:59 -0700 Message-ID: <1500064799.2853.36.camel@HansenPartnership.com> In-Reply-To: <1500062619.3583.71.camel@linux.vnet.ibm.com> List-Id: --===============6537097551690675334== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote: > On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote: > > = > > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: > > > = > > > The concern is with a shared filesystems. =C2=A0In that case, for IMA > > > it would make sense to support a native and a namespace xattr. > > > =C2=A0If 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=3D" tag - first namespace gets permission to > > > write the namespace xattr. =C2=A0Again, like in the layered case, if > > > the namespace xattr doesn't exist, fall back to using the native > > > xattr. > > = > > Just on this point: if we're really concerned about the need on > > shared filesystems to have multiple IMA signatures per file, might > > it not make sense simply to support multiple signatures within the > > security.ima xattr? The rules for writing signature updates within > > user namespaces would be somewhat complex (say only able to replace > > a signature for which you demonstrate you possess the key) but it > > would lead to an implementation which would work for traditional > > shared filesystems (like NFS) as well as containerised bind mounts. > = > Writing security.ima requires being root with CAP_SYS_ADMIN > privileges. =C2=A0I wouldn't want to give root within the namespace > permission to over write or just extend the native security.ima. but why? =C2=A0That'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. =C2=A0What 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? James --===============6537097551690675334==--