From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752562AbcAFCN2 (ORCPT ); Tue, 5 Jan 2016 21:13:28 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:50756 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751985AbcAFCNX (ORCPT ); Tue, 5 Jan 2016 21:13:23 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Josh Boyer , "Serge E. Hallyn" , Jann Horn , Roland McGrath , Oleg Nesterov , "linux-kernel\@vger.kernel.org" , "security\@kernel.org" , Serge Hallyn , Linus Torvalds References: <20151226011038.GA25455@pc.thejh.net> <1451098351-8917-1-git-send-email-jann@thejh.net> <20151226215101.GB21578@mail.hallyn.com> <87y4c3ld5s.fsf@x220.int.ebiederm.org> Date: Tue, 05 Jan 2016 20:04:29 -0600 In-Reply-To: (Andy Lutomirski's message of "Tue, 5 Jan 2016 17:36:33 -0800") Message-ID: <8760z7fope.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: U2FsdGVkX1+X7stDWaZrmY0e/d7xLF+bRPg67QI6uz0= X-SA-Exim-Connect-IP: 97.121.81.63 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 1068 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 4.1 (0.4%), b_tie_ro: 3.0 (0.3%), parse: 1.04 (0.1%), extract_message_metadata: 25 (2.4%), get_uri_detail_list: 4.9 (0.5%), tests_pri_-1000: 11 (1.0%), tests_pri_-950: 1.22 (0.1%), tests_pri_-900: 1.01 (0.1%), tests_pri_-400: 32 (3.0%), check_bayes: 31 (2.9%), b_tokenize: 10 (0.9%), b_tok_get_all: 11 (1.0%), b_comp_prob: 3.4 (0.3%), b_tok_touch_all: 3.8 (0.4%), b_finish: 0.78 (0.1%), tests_pri_0: 367 (34.4%), check_dkim_signature: 0.49 (0.0%), check_dkim_adsp: 3.7 (0.4%), tests_pri_500: 622 (58.2%), poll_dns_idle: 616 (57.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] ptrace: being capable wrt a process requires mapped uids/gids X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -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 Andy Lutomirski writes: > On Tue, Jan 5, 2016 at 5:17 PM, Eric W. Biederman wrote: >> Josh Boyer writes: >> >>> On Sat, Dec 26, 2015 at 9:03 PM, Andy Lutomirski wrote: >>>> On Sat, Dec 26, 2015 at 1:51 PM, Serge E. Hallyn >>>> wrote: >>>>> On Sat, Dec 26, 2015 at 03:52:31AM +0100, Jann Horn wrote: >>>>>> ptrace_has_cap() checks whether the current process should be >>>>>> treated as having a certain capability for ptrace checks >>>>>> against another process. Until now, this was equivalent to >>>>>> has_ns_capability(current, target_ns, CAP_SYS_PTRACE). >>>>>> >>>>>> However, if a root-owned process wants to enter a user >>>>>> namespace for some reason without knowing who owns it and >>>>>> therefore can't change to the namespace owner's uid and gid >>>>>> before entering, as soon as it has entered the namespace, >>>>>> the namespace owner can attach to it via ptrace and thereby >>>>>> gain access to its uid and gid. >>>>>> >>>>>> While it is possible for the entering process to switch to >>>>>> the uid of a claimed namespace owner before entering, >>>>>> causing the attempt to enter to fail if the claimed uid is >>>>>> wrong, this doesn't solve the problem of determining an >>>>>> appropriate gid. >>>>>> >>>>>> With this change, the entering process can first enter the >>>>>> namespace and then safely inspect the namespace's >>>>>> properties, e.g. through /proc/self/{uid_map,gid_map}, >>>>>> assuming that the namespace owner doesn't have access to >>>>>> uid 0. >>>>>> >>>>>> Changed in v2: The caller needs to be capable in the >>>>>> namespace into which tcred's uids/gids can be mapped. >>>>>> >>>>>> Signed-off-by: Jann Horn >>>>> >>>>> Acked-by: Serge Hallyn >>>> >>>> Acked-by: Andy Lutomirski >>>> >>>> Who's going to apply this? Linus? Eric? >>> >>> An Ack from Oleg would be nice too. I'm guessing this got lost in the >>> holidays but it has an assigned CVE now. Would be good to get it in >>> 4.4 final. >> >> If people are going to go around and refuse to understand the problem >> and assign CVEs to the kernel when they can't understand what is >> necessary to safely write code I am inclined to nack the entire mess. >> >> Whatever (if anything) that is calling setns in this problematic way is >> the problem today. >> > > Even if we were to grant that the setns caller is buggy, this patch > seems like a good hardening measure. Is there any case where ptrace > access *should* be granted but would not be granted with this patch > applied? Honestly I rather like the direction of this patch. This patch seems to be upholding the old princimple that you are not allowed to trace a process that has security relevant resources you could not access any other way. In this case uids. As for the question of does this break userspace. The only preexisting case that this even comes close to is ptracing user mode helpers. All of the existing ptrace hardening in yama actually blocks this case because the of the disjoint process tree. So I don't think we are going to break userspace by changing behavior here. I can see a strong argument for wanting ptrace to work from this process to other processes in the user namespace. Because setns/nsenter is what you use when you want to debug what is wrong in a container. That said I don't think it will ever be easy, to write safe code, that places a process into a user namespace with a hostile user namespace root. We can certainly help by tweaking a few things but it won't be easy. In writing a process that cass setns and enters a potentially hostile user namespace you have to be aware of what resource your process is holding onto and have to carefully drop them. In this case I am wondering if it might be smart to also consider setting dumpable (or some version of dumpable) when we call setns and enter a user namespace. >> This thread is about a feature request to make it easier to write secure >> code not about a vulnerability in user namespaces. > > So what? Viewing this as a vulnerability in user namespaces is problematic because it encourages people to write buggy code. Plus I get people asking me what is going on with CVExyz. So I am answering them there is no kernel bug here. Eric