From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752044AbcKQXra (ORCPT ); Thu, 17 Nov 2016 18:47:30 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:47752 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbcKQXr2 (ORCPT ); Thu, 17 Nov 2016 18:47:28 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Linux Containers , Oleg Nesterov , "linux-kernel\@vger.kernel.org" , "linux-mm\@kvack.org" , Linux FS Devel , Michal Hocko , Jann Horn , Willy Tarreau , Kees Cook References: <87twcbq696.fsf@x220.int.ebiederm.org> <20161018135031.GB13117@dhcp22.suse.cz> <8737jt903u.fsf@xmission.com> <20161018150507.GP14666@pc.thejh.net> <87twc9656s.fsf@xmission.com> <20161018191206.GA1210@laptop.thejh.net> <87r37dnz74.fsf@xmission.com> <87k2d5nytz.fsf_-_@xmission.com> <87y41kjn6l.fsf@xmission.com> <20161019172917.GE1210@laptop.thejh.net> <87pomwi5p2.fsf@xmission.com> <87pomwghda.fsf@xmission.com> <87twb6avk8.fsf_-_@xmission.com> <87oa1eavfx.fsf_-_@xmission.com> Date: Thu, 17 Nov 2016 17:44:46 -0600 In-Reply-To: (Andy Lutomirski's message of "Thu, 17 Nov 2016 15:27:09 -0800") Message-ID: <87twb5y8lt.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=1c7WOk-0002v2-Iu;;;mid=<87twb5y8lt.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=75.170.125.99;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18wReYEUcI73pJ38/2KkdKWRF4MfDQBle0= X-SA-Exim-Connect-IP: 75.170.125.99 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 * 1.5 TR_Symld_Words too many words that have symbols inside * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 6016 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.8 (0.1%), b_tie_ro: 2.7 (0.0%), parse: 1.16 (0.0%), extract_message_metadata: 16 (0.3%), get_uri_detail_list: 2.5 (0.0%), tests_pri_-1000: 7 (0.1%), tests_pri_-950: 1.39 (0.0%), tests_pri_-900: 1.07 (0.0%), tests_pri_-400: 29 (0.5%), check_bayes: 28 (0.5%), b_tokenize: 8 (0.1%), b_tok_get_all: 9 (0.1%), b_comp_prob: 2.3 (0.0%), b_tok_touch_all: 5 (0.1%), b_finish: 1.93 (0.0%), tests_pri_0: 191 (3.2%), check_dkim_signature: 0.48 (0.0%), check_dkim_adsp: 3.0 (0.1%), tests_pri_500: 5762 (95.8%), poll_dns_idle: 5754 (95.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [REVIEW][PATCH 1/3] ptrace: Capture the ptracer's creds not PT_PTRACE_CAP 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 Andy Lutomirski writes: > On Thu, Nov 17, 2016 at 9:05 AM, Eric W. Biederman > wrote: >> >> When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was >> overlooked. This can result in incorrect behavior when an application >> like strace traces an exec of a setuid executable. >> >> Further PT_PTRACE_CAP does not have enough information for making good >> security decisions as it does not report which user namespace the >> capability is in. This has already allowed one mistake through >> insufficient granulariy. >> >> I found this issue when I was testing another corner case of exec and >> discovered that I could not get strace to set PT_PTRACE_CAP even when >> running strace as root with a full set of caps. >> >> This change fixes the above issue with strace allowing stracing as >> root a setuid executable without disabling setuid. More fundamentaly >> this change allows what is allowable at all times, by using the correct >> information in it's decision. >> >> Cc: stable@vger.kernel.org >> Fixes: 4214e42f96d4 ("v2.4.9.11 -> v2.4.9.12") >> Signed-off-by: "Eric W. Biederman" >> --- >> fs/exec.c | 2 +- >> include/linux/capability.h | 1 + >> include/linux/ptrace.h | 1 - >> include/linux/sched.h | 1 + >> kernel/capability.c | 20 ++++++++++++++++++++ >> kernel/ptrace.c | 12 +++++++----- >> 6 files changed, 30 insertions(+), 7 deletions(-) >> >> diff --git a/fs/exec.c b/fs/exec.c >> index 6fcfb3f7b137..fdec760bfac3 100644 >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1401,7 +1401,7 @@ static void check_unsafe_exec(struct linux_binprm *bprm) >> unsigned n_fs; >> >> if (p->ptrace) { >> - if (p->ptrace & PT_PTRACE_CAP) >> + if (ptracer_capable(p, current_user_ns())) > > IIRC PT_PTRACE_CAP was added to prevent TOCTOU races. What prevents > that type of race now? For that matter, what guarantees that we've > already switched to new creds here and will continue to do so in the > future? Because instead of capturing a single bit we now capture tracers entire credentials in tsk->ptracer_cred. As such tsk->ptracer_cred never changes except when ptracing begins or ends, and we remain safe for TOCTOU races. We do hold cred_guard_mutex here so that guarantees we get a new ptracer. So the worst that can happen here is our tracer detaches and ptracer_capable will uncondintionally return true. Eric