From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [PATCH] user-namespaced file capabilities - now with even more magic Date: Fri, 27 May 2016 14:33:45 -0500 Message-ID: <87y46vcn3a.fsf@x220.int.ebiederm.org> References: <20160527071807.GA501@mail.hallyn.com> <87y46ve3oe.fsf@x220.int.ebiederm.org> <20160527191034.GA11575@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20160527191034.GA11575-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org> (Serge E. Hallyn's message of "Fri, 27 May 2016 14:10:34 -0500") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Serge E. Hallyn" Cc: LKML , Jann Horn , Seth Forshee , LSM , "Andrew G. Morgan" , Kees Cook , Michael Kerrisk-manpages , Linux API , Andy Lutomirski , Linux Containers , Mimi Zohar List-Id: linux-api@vger.kernel.org "Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org): >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name, >> > const void *value, size_t size, int flags) >> > { >> > if (!strcmp(name, XATTR_NAME_CAPS)) { >> > - if (!capable(CAP_SETFCAP)) >> > + /* Note - we want to use Seth's newer code here instead >> > */ >> ^^^^^^^^^^^^^^^ What are you referring to here? current_in_userns? > > Referring specifically to > > http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/security/commoncap.c?id=e1804ed91602bc8ead616c9616de70096b139fa7 > > I just need to think about what precisely we want the rule to be here. > > It's possible we just drop Seth's patch, as mine already allows writing > capabilities (though not v2) when not in init_user_ns, so his patch isn't > needed. > > Seth's patch makes it possible to write v2 capabilitie (which are not > namespaced) to a file in non-init user-ns if the userns mounted the fs. > > Mine does not allow that, ever, but will silently write a v3 capability. > > Seth's patch never allows writing a file capability unlesss the whole > block device was mountd by the caller's user-ns. Mine allows writing > v3 capabilities to such files. > > So yeah, maybe mine simiply obviates the need for Seths' patch. Hmm. While there is an obvious conflict the two patches are doing different things. s_user_ns is the owning user namespace of the filesystem. And as such it is fine to write the old capability in that context. You are making it possible to write the capability in child user namespaces, and I presume not allowing stomping a capability set by a more privileged user. Unless you update your code to decide to write a v2 capability if rootid is zero and v3 otherwise the code will still have interesting entanglement issues. Even then the code needs to look at s_user_ns to see what rootid should be. Earlier today I pushed a for-testing branch to my user-namespace.git tree and that has the start of the s_user_ns stuff that I am pretty much ready to merge at this point. I still need to rebase onto 4.7-rc1 and retest before I get farther. But I am serious about getting this stuff reviewed and merged into my tree and into Linus' tree next merge window. It is way past time. 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 S1755854AbcE0TpV (ORCPT ); Fri, 27 May 2016 15:45:21 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:42262 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751307AbcE0TpS (ORCPT ); Fri, 27 May 2016 15:45:18 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: LKML , Jann Horn , Seth Forshee , LSM , "Andrew G. Morgan" , Kees Cook , Michael Kerrisk-manpages , Linux API , Andy Lutomirski , Linux Containers , Mimi Zohar References: <20160527071807.GA501@mail.hallyn.com> <87y46ve3oe.fsf@x220.int.ebiederm.org> <20160527191034.GA11575@mail.hallyn.com> Date: Fri, 27 May 2016 14:33:45 -0500 In-Reply-To: <20160527191034.GA11575@mail.hallyn.com> (Serge E. Hallyn's message of "Fri, 27 May 2016 14:10:34 -0500") Message-ID: <87y46vcn3a.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX19kSyBPvGgXsQdSX37k6UWhdn1k6m1ZsFA= X-SA-Exim-Connect-IP: 97.119.107.188 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Timing: total 672 ms - load_scoreonly_sql: 0.06 (0.0%), signal_user_changed: 4.9 (0.7%), b_tie_ro: 3.8 (0.6%), parse: 1.21 (0.2%), extract_message_metadata: 35 (5.2%), get_uri_detail_list: 3.7 (0.6%), tests_pri_-1000: 16 (2.4%), tests_pri_-950: 2.2 (0.3%), tests_pri_-900: 1.72 (0.3%), tests_pri_-400: 41 (6.1%), check_bayes: 39 (5.8%), b_tokenize: 14 (2.1%), b_tok_get_all: 10 (1.4%), b_comp_prob: 5.0 (0.7%), b_tok_touch_all: 6 (0.8%), b_finish: 0.92 (0.1%), tests_pri_0: 557 (82.8%), check_dkim_signature: 0.95 (0.1%), check_dkim_adsp: 7 (1.1%), tests_pri_500: 8 (1.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] user-namespaced file capabilities - now with even more magic 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 in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "Serge E. Hallyn" writes: > Quoting Eric W. Biederman (ebiederm@xmission.com): >> > @@ -657,8 +898,11 @@ int cap_inode_setxattr(struct dentry *dentry, const char *name, >> > const void *value, size_t size, int flags) >> > { >> > if (!strcmp(name, XATTR_NAME_CAPS)) { >> > - if (!capable(CAP_SETFCAP)) >> > + /* Note - we want to use Seth's newer code here instead >> > */ >> ^^^^^^^^^^^^^^^ What are you referring to here? current_in_userns? > > Referring specifically to > > http://kernel.ubuntu.com/git/ubuntu/ubuntu-yakkety.git/commit/security/commoncap.c?id=e1804ed91602bc8ead616c9616de70096b139fa7 > > I just need to think about what precisely we want the rule to be here. > > It's possible we just drop Seth's patch, as mine already allows writing > capabilities (though not v2) when not in init_user_ns, so his patch isn't > needed. > > Seth's patch makes it possible to write v2 capabilitie (which are not > namespaced) to a file in non-init user-ns if the userns mounted the fs. > > Mine does not allow that, ever, but will silently write a v3 capability. > > Seth's patch never allows writing a file capability unlesss the whole > block device was mountd by the caller's user-ns. Mine allows writing > v3 capabilities to such files. > > So yeah, maybe mine simiply obviates the need for Seths' patch. Hmm. While there is an obvious conflict the two patches are doing different things. s_user_ns is the owning user namespace of the filesystem. And as such it is fine to write the old capability in that context. You are making it possible to write the capability in child user namespaces, and I presume not allowing stomping a capability set by a more privileged user. Unless you update your code to decide to write a v2 capability if rootid is zero and v3 otherwise the code will still have interesting entanglement issues. Even then the code needs to look at s_user_ns to see what rootid should be. Earlier today I pushed a for-testing branch to my user-namespace.git tree and that has the start of the s_user_ns stuff that I am pretty much ready to merge at this point. I still need to rebase onto 4.7-rc1 and retest before I get farther. But I am serious about getting this stuff reviewed and merged into my tree and into Linus' tree next merge window. It is way past time. Eric