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: Tue, 18 Jul 2017 08:26:37 -0500 Message-ID: <871spdj2pe.fsf@xmission.com> References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: (Stefan Berger's message of "Tue, 18 Jul 2017 08:12:13 -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/18/2017 03:01 AM, James Morris wrote: >> On Thu, 13 Jul 2017, Stefan Berger wrote: >> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once >>> these containers set xattrs on that file. >> I may be missing something here, but what happens when say the uid=2000 >> container and associated user is deleted from the system, then another is >> created with the same uid? >> >> Won't this mean that you have unexpected capabilities turning up in the >> new container? >> > > Yes, that's right. I don't know any solution for that. We would have to walk the > filesystems and find all 'stale' xattrs with such a uid. This is independent of > whether the uid is encoded on the name side, as in this patch, or on the value > side, as in Serge's original proposal. And uids of a mapped container root user > don't necessarily have to have an account on the host so that an account > deletion could trigger that. This problem is actually independent of this piece of code entirely. Any lingering files owned by that uid have the same issue. Uids are are persistent system property. It must be arranged that they are managed carefully. If you want to reuse a uid userdel or the equivalent must be able to go out and delete everything they have owned. Which is to say fundamentally this is userspaces's responsibility. I don't see this as being particularly subtle or novel. We already track which uids and which subordinate uids go together. I will nack anything that allows multiple capability attributes per file as we have established they are unnecessary. So I don't see any scenarios where this is likely to come up that it would not be a problem without these uid tagged security capabilities. 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 S1751490AbdGRNel (ORCPT ); Tue, 18 Jul 2017 09:34:41 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:59727 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751401AbdGRNei (ORCPT ); Tue, 18 Jul 2017 09:34:38 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Stefan Berger Cc: James Morris , "Theodore Ts'o" , "Serge E. Hallyn" , 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: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce@linux.vnet.ibm.com> Date: Tue, 18 Jul 2017 08:26:37 -0500 In-Reply-To: (Stefan Berger's message of "Tue, 18 Jul 2017 08:12:13 -0400") Message-ID: <871spdj2pe.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=1dXSe2-0008Sr-JD;;;mid=<871spdj2pe.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.213.87;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+zHgaoXKj/DA+dvD7deIaNLOVU25gLNao= 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.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 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.4532] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] * 0.2 T_XMDrugObfuBody_14 obfuscated drug references X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Stefan Berger X-Spam-Relay-Country: X-Spam-Timing: total 512 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 3.6 (0.7%), b_tie_ro: 2.4 (0.5%), parse: 1.41 (0.3%), extract_message_metadata: 5 (1.0%), get_uri_detail_list: 2.4 (0.5%), tests_pri_-1000: 6 (1.2%), tests_pri_-950: 1.73 (0.3%), tests_pri_-900: 1.48 (0.3%), tests_pri_-400: 28 (5.4%), check_bayes: 26 (5.2%), b_tokenize: 10 (2.0%), b_tok_get_all: 8 (1.5%), b_comp_prob: 3.2 (0.6%), b_tok_touch_all: 2.7 (0.5%), b_finish: 0.73 (0.1%), tests_pri_0: 448 (87.7%), check_dkim_signature: 0.60 (0.1%), check_dkim_adsp: 9 (1.8%), tests_pri_500: 3.7 (0.7%), 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/18/2017 03:01 AM, James Morris wrote: >> On Thu, 13 Jul 2017, Stefan Berger wrote: >> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once >>> these containers set xattrs on that file. >> I may be missing something here, but what happens when say the uid=2000 >> container and associated user is deleted from the system, then another is >> created with the same uid? >> >> Won't this mean that you have unexpected capabilities turning up in the >> new container? >> > > Yes, that's right. I don't know any solution for that. We would have to walk the > filesystems and find all 'stale' xattrs with such a uid. This is independent of > whether the uid is encoded on the name side, as in this patch, or on the value > side, as in Serge's original proposal. And uids of a mapped container root user > don't necessarily have to have an account on the host so that an account > deletion could trigger that. This problem is actually independent of this piece of code entirely. Any lingering files owned by that uid have the same issue. Uids are are persistent system property. It must be arranged that they are managed carefully. If you want to reuse a uid userdel or the equivalent must be able to go out and delete everything they have owned. Which is to say fundamentally this is userspaces's responsibility. I don't see this as being particularly subtle or novel. We already track which uids and which subordinate uids go together. I will nack anything that allows multiple capability attributes per file as we have established they are unnecessary. So I don't see any scenarios where this is likely to come up that it would not be a problem without these uid tagged security capabilities. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Date: Tue, 18 Jul 2017 08:26:37 -0500 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: (Stefan Berger's message of "Tue, 18 Jul 2017 08:12:13 -0400") References: <1499785511-17192-1-git-send-email-stefanb@linux.vnet.ibm.com> <1499785511-17192-2-git-send-email-stefanb@linux.vnet.ibm.com> <87mv89iy7q.fsf@xmission.com> <20170712170346.GA17974@mail.hallyn.com> <877ezdgsey.fsf@xmission.com> <74664cc8-bc3e-75d6-5892-f8934404349f@linux.vnet.ibm.com> <20170713011554.xwmrgkzfwnibvgcu@thunk.org> <87y3rscz9j.fsf@xmission.com> <20170713164012.brj2flnkaaks2oci@thunk.org> <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce@linux.vnet.ibm.com> Message-ID: <871spdj2pe.fsf@xmission.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Stefan Berger writes: > On 07/18/2017 03:01 AM, James Morris wrote: >> On Thu, 13 Jul 2017, Stefan Berger wrote: >> >>> A file shared by 2 containers, one mapping root to uid=1000, the other mapping >>> root to uid=2000, will show these two xattrs on the host (init_user_ns) once >>> these containers set xattrs on that file. >> I may be missing something here, but what happens when say the uid=2000 >> container and associated user is deleted from the system, then another is >> created with the same uid? >> >> Won't this mean that you have unexpected capabilities turning up in the >> new container? >> > > Yes, that's right. I don't know any solution for that. We would have to walk the > filesystems and find all 'stale' xattrs with such a uid. This is independent of > whether the uid is encoded on the name side, as in this patch, or on the value > side, as in Serge's original proposal. And uids of a mapped container root user > don't necessarily have to have an account on the host so that an account > deletion could trigger that. This problem is actually independent of this piece of code entirely. Any lingering files owned by that uid have the same issue. Uids are are persistent system property. It must be arranged that they are managed carefully. If you want to reuse a uid userdel or the equivalent must be able to go out and delete everything they have owned. Which is to say fundamentally this is userspaces's responsibility. I don't see this as being particularly subtle or novel. We already track which uids and which subordinate uids go together. I will nack anything that allows multiple capability attributes per file as we have established they are unnecessary. So I don't see any scenarios where this is likely to come up that it would not be a problem without these uid tagged security capabilities. 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="===============9084477072754293348==" 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: Tue, 18 Jul 2017 08:26:37 -0500 Message-ID: <871spdj2pe.fsf@xmission.com> In-Reply-To: List-Id: --===============9084477072754293348== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Stefan Berger writes: > On 07/18/2017 03:01 AM, James Morris wrote: >> On Thu, 13 Jul 2017, Stefan Berger wrote: >> >>> A file shared by 2 containers, one mapping root to uid=3D1000, the othe= r mapping >>> root to uid=3D2000, will show these two xattrs on the host (init_user_n= s) once >>> these containers set xattrs on that file. >> I may be missing something here, but what happens when say the uid=3D2000 >> container and associated user is deleted from the system, then another is >> created with the same uid? >> >> Won't this mean that you have unexpected capabilities turning up in the >> new container? >> > > Yes, that's right. I don't know any solution for that. We would have to w= alk the > filesystems and find all 'stale' xattrs with such a uid. This is independ= ent of > whether the uid is encoded on the name side, as in this patch, or on the = value > side, as in Serge's original proposal. And uids of a mapped container roo= t user > don't necessarily have to have an account on the host so that an account > deletion could trigger that. This problem is actually independent of this piece of code entirely. Any lingering files owned by that uid have the same issue. Uids are are persistent system property. It must be arranged that they are managed carefully. If you want to reuse a uid userdel or the equivalent must be able to go out and delete everything they have owned. Which is to say fundamentally this is userspaces's responsibility. I don't see this as being particularly subtle or novel. We already track which uids and which subordinate uids go together. I will nack anything that allows multiple capability attributes per file as we have established they are unnecessary. So I don't see any scenarios where this is likely to come up that it would not be a problem without these uid tagged security capabilities. Eric --===============9084477072754293348==--