From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Fri, 14 Jul 2017 12:36:46 -0500 Message-ID: <87pod22a4x.fsf@xmission.com> References: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <596f808b-e21d-8296-5fef-23c1ce7ab778-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> (Stefan Berger's message of "Fri, 14 Jul 2017 11:22:28 -0400") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Stefan Berger Cc: Theodore Ts'o , zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org, containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org, lkp-JC7UmRfGjtg@public.gmane.org List-Id: containers.vger.kernel.org Stefan Berger writes: > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org): >>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >>>> Stefan Berger 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@... 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@uid=<> or just a single one security.foo(@[[:print:]]*)? >>>>> >>>> The latter. >>> That case would prevent a container user from overriding the xattr >>> on the host. Is that what we want? For limiting the number of xattrs >> Not really. If the file is owned by a uid mapped into the container, >> then the container root can chown the file which will clear the file >> capability, after which he can set a new one. If the file is not >> owned by a uid mapped into the container, then container root could >> not set a filecap anyway. > > Let's say I installed a container where all files are signed and thus have > security.ima. Now for some reason I want to re-sign some or all files inside > that container. How would I do that ? Would I 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@uid=1000 besides the security.ima ? This gets us into some interesting territory, where the semantics of these attributes matters. The implementation of security.capable implements the security killpriv hooks. Anyone merely by changing the file can cause the security capability to go away. So it makes sense from the security.capable side that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be able to clear and set security.capable. The integrity xattrs do not. Which results in very big semantic difference between these two kinds of attributes. I am insufficiently familiar with the rules for security.ima and security.evm to understand what those rules should be. That may be enough that we can not share code between these two cases. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751092AbdGNS5v (ORCPT ); Fri, 14 Jul 2017 14:57:51 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:39588 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750925AbdGNS5t (ORCPT ); Fri, 14 Jul 2017 14:57:49 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Stefan Berger Cc: "Serge E. Hallyn" , "Theodore Ts'o" , containers@lists.linux-foundation.org, lkp@01.org, linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com, 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 References: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <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> Date: Fri, 14 Jul 2017 12:36:46 -0500 In-Reply-To: <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> (Stefan Berger's message of "Fri, 14 Jul 2017 11:22:28 -0400") Message-ID: <87pod22a4x.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1dW4ds-0007Px-8j;;;mid=<87pod22a4x.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/RzkUANKuAxe5dZd61AVffwtZEPk9sOkE= X-SA-Exim-Connect-IP: 67.3.213.87 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4996] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Stefan Berger X-Spam-Relay-Country: X-Spam-Timing: total 5837 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.6 (0.0%), b_tie_ro: 1.79 (0.0%), parse: 0.81 (0.0%), extract_message_metadata: 15 (0.3%), get_uri_detail_list: 2.2 (0.0%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.17 (0.0%), tests_pri_-900: 1.01 (0.0%), tests_pri_-400: 24 (0.4%), check_bayes: 23 (0.4%), b_tokenize: 8 (0.1%), b_tok_get_all: 8 (0.1%), b_comp_prob: 2.7 (0.0%), b_tok_touch_all: 2.8 (0.0%), b_finish: 0.69 (0.0%), tests_pri_0: 241 (4.1%), check_dkim_signature: 0.49 (0.0%), check_dkim_adsp: 3.4 (0.1%), tests_pri_500: 5542 (95.0%), poll_dns_idle: 5537 (94.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stefan Berger writes: > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): >>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >>>> Stefan Berger 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@... 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@uid=<> or just a single one security.foo(@[[:print:]]*)? >>>>> >>>> The latter. >>> That case would prevent a container user from overriding the xattr >>> on the host. Is that what we want? For limiting the number of xattrs >> Not really. If the file is owned by a uid mapped into the container, >> then the container root can chown the file which will clear the file >> capability, after which he can set a new one. If the file is not >> owned by a uid mapped into the container, then container root could >> not set a filecap anyway. > > Let's say I installed a container where all files are signed and thus have > security.ima. Now for some reason I want to re-sign some or all files inside > that container. How would I do that ? Would I 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@uid=1000 besides the security.ima ? This gets us into some interesting territory, where the semantics of these attributes matters. The implementation of security.capable implements the security killpriv hooks. Anyone merely by changing the file can cause the security capability to go away. So it makes sense from the security.capable side that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be able to clear and set security.capable. The integrity xattrs do not. Which results in very big semantic difference between these two kinds of attributes. I am insufficiently familiar with the rules for security.ima and security.evm to understand what those rules should be. That may be enough that we can not share code between these two cases. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Fri, 14 Jul 2017 12:36:46 -0500 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> (Stefan Berger's message of "Fri, 14 Jul 2017 11:22:28 -0400") References: <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <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> Message-ID: <87pod22a4x.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Stefan Berger writes: > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stefanb at linux.vnet.ibm.com): >>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >>>> Stefan Berger 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 ? >>>>> 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:]]*)? >>>>> >>>> The latter. >>> That case would prevent a container user from overriding the xattr >>> on the host. Is that what we want? For limiting the number of xattrs >> Not really. If the file is owned by a uid mapped into the container, >> then the container root can chown the file which will clear the file >> capability, after which he can set a new one. If the file is not >> owned by a uid mapped into the container, then container root could >> not set a filecap anyway. > > Let's say I installed a container where all files are signed and thus have > security.ima. Now for some reason I want to re-sign some or all files inside > that container. How would I do that ? Would I 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 security.ima ? This gets us into some interesting territory, where the semantics of these attributes matters. The implementation of security.capable implements the security killpriv hooks. Anyone merely by changing the file can cause the security capability to go away. So it makes sense from the security.capable side that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be able to clear and set security.capable. The integrity xattrs do not. Which results in very big semantic difference between these two kinds of attributes. I am insufficiently familiar with the rules for security.ima and security.evm to understand what those rules should be. That may be enough that we can not share code between these two cases. 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0258817852581602303==" MIME-Version: 1.0 From: Eric W. Biederman To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Fri, 14 Jul 2017 12:36:46 -0500 Message-ID: <87pod22a4x.fsf@xmission.com> In-Reply-To: <596f808b-e21d-8296-5fef-23c1ce7ab778@linux.vnet.ibm.com> List-Id: --===============0258817852581602303== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Stefan Berger writes: > On 07/14/2017 09:34 AM, Serge E. Hallyn wrote: >> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com): >>> On 07/13/2017 08:38 PM, Eric W. Biederman wrote: >>>> Stefan Berger 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(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(a)uid=3D<>= or just a single one security.foo(@[[:print:]]*)? >>>>> >>>> The latter. >>> That case would prevent a container user from overriding the xattr >>> on the host. Is that what we want? For limiting the number of xattrs >> Not really. If the file is owned by a uid mapped into the container, >> then the container root can chown the file which will clear the file >> capability, after which he can set a new one. If the file is not >> owned by a uid mapped into the container, then container root could >> not set a filecap anyway. > > Let's say I installed a container where all files are signed and thus have > security.ima. Now for some reason I want to re-sign some or all files ins= ide > that container. How would I do that ? Would I need to get rid of security= .ima > first, possibly by copying each file, deleting the original file, and ren= aming > the copied file to the original name, or should I just be able to write o= ut a > new signature, thus creating security.ima(a)uid=3D1000 besides the securi= ty.ima ? This gets us into some interesting territory, where the semantics of these attributes matters. The implementation of security.capable implements the security killpriv hooks. Anyone merely by changing the file can cause the security capability to go away. So it makes sense from the security.capable side that anyone who has the capable_wrt_inode_uidgid(CAP_SETFCAP) will be able to clear and set security.capable. The integrity xattrs do not. Which results in very big semantic difference between these two kinds of attributes. I am insufficiently familiar with the rules for security.ima and security.evm to understand what those rules should be. That may be enough that we can not share code between these two cases. Eric --===============0258817852581602303==--