From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CC88C433EF for ; Wed, 8 Sep 2021 14:21:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 290206113D for ; Wed, 8 Sep 2021 14:21:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351783AbhIHOWj (ORCPT ); Wed, 8 Sep 2021 10:22:39 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:42616 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229600AbhIHOWh (ORCPT ); Wed, 8 Sep 2021 10:22:37 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]:37094) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mNyS5-002ZZZ-SF; Wed, 08 Sep 2021 08:21:25 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:42036 helo=email.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mNyS4-00BBdJ-GW; Wed, 08 Sep 2021 08:21:25 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Miklos Szeredi Cc: Vivek Goyal , "Dr. David Alan Gilbert" , Andreas Gruenbacher , Alexander Viro , linux-fsdevel , LKML , virtio-fs-list , Daniel J Walsh , Christian Brauner , Casey Schaufler , LSM , SElinux list , "Theodore Ts'o" , Giuseppe Scrivano , "Fields\, Bruce" , Stephen Smalley , Dave Chinner , "Serge E. Hallyn" References: <20210902152228.665959-1-vgoyal@redhat.com> Date: Wed, 08 Sep 2021 09:20:32 -0500 In-Reply-To: (Miklos Szeredi's message of "Wed, 8 Sep 2021 09:37:17 +0200") Message-ID: <87lf47tahb.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mNyS4-00BBdJ-GW;;;mid=<87lf47tahb.fsf@disp2133>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+SrgV0tKVopvxRdxK+6dEdGv6cwF2N0VI= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v3 0/1] Relax restrictions on user.* xattr X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi writes: > On Tue, 7 Sept 2021 at 23:40, Vivek Goyal wrote: >> >> On Mon, Sep 06, 2021 at 04:56:44PM +0200, Miklos Szeredi wrote: >> > On Mon, 6 Sept 2021 at 16:39, Dr. David Alan Gilbert >> > wrote: >> > >> > > IMHO the real problem here is that the user/trusted/system/security >> > > 'namespaces' are arbitrary hacks rather than a proper namespacing >> > > mechanism that allows you to create new (nested) namespaces and associate >> > > permissions with each one. >> > >> > Indeed. >> > >> > This is what Eric Biederman suggested at some point for supporting >> > trusted xattrs within a user namespace: >> > >> > | For trusted xattrs I think it makes sense in principle. The namespace >> > | would probably become something like "trusted.". >> > >> > Theory sounds simple enough. Anyone interested in looking at the details? >> >> So this namespaced trusted.* xattr domain will basically avoid the need >> to have CAP_SYS_ADMIN in init_user_ns, IIUC. I guess this is better >> than giving CAP_SYS_ADMIN in init_user_ns. > > That's the objective, yes. I think the trick is getting filesystems > to store yet another xattr type. Using the uid of the root user of a user namespace is probably the best idea we have so far for identifying a user namespace in persistent on-disk meta-data. We ran into a little trouble using that idea for file capabilities. The key problem was there are corner cases where some nested user namespaces have the same root user id as their parent namespaces. This has the potential to allow privilege escalation if the creator of the user namespace does not have sufficient capabilities. The solution we adopted can be seen in db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0"). That solution is basically not allowing the creation of user namespaces that could have problems. I think use trusted xattrs this way the code would need to treat CAP_SYS_ADMIN the same way it currently treats CAP_SETFCAP. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) References: <20210902152228.665959-1-vgoyal@redhat.com> Date: Wed, 08 Sep 2021 09:20:32 -0500 In-Reply-To: (Miklos Szeredi's message of "Wed, 8 Sep 2021 09:37:17 +0200") Message-ID: <87lf47tahb.fsf@disp2133> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Virtio-fs] [PATCH v3 0/1] Relax restrictions on user.* xattr List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miklos Szeredi Cc: Giuseppe Scrivano , Theodore Ts'o , Andreas Gruenbacher , SElinux list , Stephen Smalley , Dave Chinner , LKML , virtio-fs-list , Casey Schaufler , LSM , Alexander Viro , linux-fsdevel , "Fields, Bruce" , Christian Brauner , Vivek Goyal , "Serge E. Hallyn" Miklos Szeredi writes: > On Tue, 7 Sept 2021 at 23:40, Vivek Goyal wrote: >> >> On Mon, Sep 06, 2021 at 04:56:44PM +0200, Miklos Szeredi wrote: >> > On Mon, 6 Sept 2021 at 16:39, Dr. David Alan Gilbert >> > wrote: >> > >> > > IMHO the real problem here is that the user/trusted/system/security >> > > 'namespaces' are arbitrary hacks rather than a proper namespacing >> > > mechanism that allows you to create new (nested) namespaces and associate >> > > permissions with each one. >> > >> > Indeed. >> > >> > This is what Eric Biederman suggested at some point for supporting >> > trusted xattrs within a user namespace: >> > >> > | For trusted xattrs I think it makes sense in principle. The namespace >> > | would probably become something like "trusted.". >> > >> > Theory sounds simple enough. Anyone interested in looking at the details? >> >> So this namespaced trusted.* xattr domain will basically avoid the need >> to have CAP_SYS_ADMIN in init_user_ns, IIUC. I guess this is better >> than giving CAP_SYS_ADMIN in init_user_ns. > > That's the objective, yes. I think the trick is getting filesystems > to store yet another xattr type. Using the uid of the root user of a user namespace is probably the best idea we have so far for identifying a user namespace in persistent on-disk meta-data. We ran into a little trouble using that idea for file capabilities. The key problem was there are corner cases where some nested user namespaces have the same root user id as their parent namespaces. This has the potential to allow privilege escalation if the creator of the user namespace does not have sufficient capabilities. The solution we adopted can be seen in db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0"). That solution is basically not allowing the creation of user namespaces that could have problems. I think use trusted xattrs this way the code would need to treat CAP_SYS_ADMIN the same way it currently treats CAP_SETFCAP. Eric