From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752889AbcKQX1d (ORCPT ); Thu, 17 Nov 2016 18:27:33 -0500 Received: from mail-vk0-f45.google.com ([209.85.213.45]:35701 "EHLO mail-vk0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbcKQX1b (ORCPT ); Thu, 17 Nov 2016 18:27:31 -0500 MIME-Version: 1.0 In-Reply-To: <87oa1eavfx.fsf_-_@xmission.com> 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> From: Andy Lutomirski Date: Thu, 17 Nov 2016 15:27:09 -0800 Message-ID: Subject: Re: [REVIEW][PATCH 1/3] ptrace: Capture the ptracer's creds not PT_PTRACE_CAP To: "Eric W. Biederman" 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 In-Reply-To: <87oa1eavfx.fsf_-_@xmission.com> 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> From: Andy Lutomirski Date: Thu, 17 Nov 2016 15:27:09 -0800 Message-ID: Subject: Re: [REVIEW][PATCH 1/3] ptrace: Capture the ptracer's creds not PT_PTRACE_CAP To: "Eric W. Biederman" 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 Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: 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? --Andy -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org