From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751508AbdGRMMi (ORCPT ); Tue, 18 Jul 2017 08:12:38 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:38059 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751388AbdGRMMg (ORCPT ); Tue, 18 Jul 2017 08:12:36 -0400 Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces To: James Morris 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> Cc: "Theodore Ts'o" , "Eric W. Biederman" , "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 From: Stefan Berger Date: Tue, 18 Jul 2017 08:12:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17071812-0008-0000-0000-00000260FCE0 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007381; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00889316; UDB=6.00444205; IPR=6.00669489; BA=6.00005478; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016261; XFM=3.00000015; UTC=2017-07-18 12:12:33 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17071812-0009-0000-0000-0000361241E9 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-18_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180190 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Stefan From mboxrd@z Thu Jan 1 00:00:00 1970 From: stefanb@linux.vnet.ibm.com (Stefan Berger) Date: Tue, 18 Jul 2017 08:12:13 -0400 Subject: [PATCH v2] xattr: Enable security.capability in user namespaces In-Reply-To: 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: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org 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. Stefan -- 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="===============7336210847370261607==" MIME-Version: 1.0 From: Stefan Berger To: lkp@lists.01.org Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces Date: Tue, 18 Jul 2017 08:12:13 -0400 Message-ID: In-Reply-To: List-Id: --===============7336210847370261607== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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 other= mapping >> root to uid=3D2000, 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=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 = 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. Stefan --===============7336210847370261607==--