From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751588AbdDBS6a (ORCPT ); Sun, 2 Apr 2017 14:58:30 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:46782 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751240AbdDBS62 (ORCPT ); Sun, 2 Apr 2017 14:58:28 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Andrew Morton , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: <87shmv6ufl.fsf@xmission.com> <20170303173326.GA17899@redhat.com> <87tw7axlr0.fsf@xmission.com> <87d1dyw5iw.fsf@xmission.com> <87tw7aunuh.fsf@xmission.com> <87lgsmunmj.fsf_-_@xmission.com> <20170304170312.GB13131@redhat.com> <8760ir192p.fsf@xmission.com> <878tnkpv8h.fsf_-_@xmission.com> <87vaqooggs.fsf_-_@xmission.com> <20170402153517.GA12637@redhat.com> Date: Sun, 02 Apr 2017 13:53:11 -0500 In-Reply-To: <20170402153517.GA12637@redhat.com> (Oleg Nesterov's message of "Sun, 2 Apr 2017 17:35:17 +0200") Message-ID: <877f32k5ew.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=1cukhl-0005oE-3t;;;mid=<877f32k5ew.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=67.3.234.240;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+yas+7YsevLl9E26xCR6WvmB6M/lxekSk= X-SA-Exim-Connect-IP: 67.3.234.240 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 * 1.5 TR_Symld_Words too many words that have symbols inside * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 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] * 1.0 T_XMHurry_00 Hurry and Do Something * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 264 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.6 (1.0%), b_tie_ro: 1.84 (0.7%), parse: 1.10 (0.4%), extract_message_metadata: 3.8 (1.4%), get_uri_detail_list: 1.74 (0.7%), tests_pri_-1000: 3.9 (1.5%), tests_pri_-950: 1.16 (0.4%), tests_pri_-900: 0.97 (0.4%), tests_pri_-400: 28 (10.5%), check_bayes: 27 (10.1%), b_tokenize: 8 (3.0%), b_tok_get_all: 7 (2.8%), b_comp_prob: 2.3 (0.9%), b_tok_touch_all: 3.2 (1.2%), b_finish: 0.65 (0.2%), tests_pri_0: 209 (79.2%), check_dkim_signature: 0.47 (0.2%), check_dkim_adsp: 2.7 (1.0%), tests_pri_500: 3.8 (1.5%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC][PATCH 2/2] exec: If possible don't wait for ptraced threads to be reaped 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 Oleg Nesterov writes: > On 04/01, Eric W. Biederman wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1052,6 +1052,7 @@ static int de_thread(struct task_struct *tsk) >> struct signal_struct *sig = tsk->signal; >> struct sighand_struct *oldsighand = tsk->sighand; >> spinlock_t *lock = &oldsighand->siglock; >> + bool may_hang; >> >> if (thread_group_empty(tsk)) >> goto no_thread_group; >> @@ -1069,9 +1070,10 @@ static int de_thread(struct task_struct *tsk) >> return -EAGAIN; >> } >> >> + may_hang = atomic_read(&oldsighand->count) != 1; >> sig->group_exit_task = tsk; >> - sig->notify_count = zap_other_threads(tsk); >> - if (!thread_group_leader(tsk)) >> + sig->notify_count = zap_other_threads(tsk, may_hang ? 1 : -1); > > Eric, this is amazing. So with this patch exec does different things depening > on whether sighand is shared with another CLONE_SIGHAND task or not. To me > this doesn't look sane in any case. It is a 99% solution that makes it possible to talk about and review letting the exec continue after the subthreads are killed but not reaped. Sigh I should have made may_hang say: may_hang = (atomic_read(&oldsignand->count) != 1) && (sig->nr_threads > 1) Which covers all know ways userspace actually uses these clone flags. > And btw zap_other_threads(may_hang == 0) is racy. Either you need tasklist or > exit_notify() should set tsk->exit_state under siglock, otherwise zap() can > return the wrong count. zap_other_thread(tsk, 0) only gets called in the case where we don't care about the return value. It does not get called from fs/exec.c > Finally. This patch creates the nice security hole. Let me modify my test-case > again: > > void *thread(void *arg) > { > ptrace(PTRACE_TRACEME, 0,0,0); > return NULL; > } > > int main(void) > { > int pid = fork(); > > if (!pid) { > pthread_t pt; > pthread_create(&pt, NULL, thread, NULL); > pthread_join(pt, NULL); > execlp(path-to-setuid-binary, args); > } > > sleep(1); > > // Now we can send the signals to setiuid app > kill(pid+1, ANYSIGNAL); > > return 0; > } That is a substantive objection, and something that definitely needs to get fixed. Can you think of anything else? Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: [RFC][PATCH 2/2] exec: If possible don't wait for ptraced threads to be reaped Date: Sun, 02 Apr 2017 13:53:11 -0500 Message-ID: <877f32k5ew.fsf@xmission.com> References: <87shmv6ufl.fsf@xmission.com> <20170303173326.GA17899@redhat.com> <87tw7axlr0.fsf@xmission.com> <87d1dyw5iw.fsf@xmission.com> <87tw7aunuh.fsf@xmission.com> <87lgsmunmj.fsf_-_@xmission.com> <20170304170312.GB13131@redhat.com> <8760ir192p.fsf@xmission.com> <878tnkpv8h.fsf_-_@xmission.com> <87vaqooggs.fsf_-_@xmission.com> <20170402153517.GA12637@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: In-Reply-To: <20170402153517.GA12637-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> (Oleg Nesterov's message of "Sun, 2 Apr 2017 17:35:17 +0200") Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Oleg Nesterov Cc: Andrew Morton , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-api@vger.kernel.org Oleg Nesterov writes: > On 04/01, Eric W. Biederman wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1052,6 +1052,7 @@ static int de_thread(struct task_struct *tsk) >> struct signal_struct *sig = tsk->signal; >> struct sighand_struct *oldsighand = tsk->sighand; >> spinlock_t *lock = &oldsighand->siglock; >> + bool may_hang; >> >> if (thread_group_empty(tsk)) >> goto no_thread_group; >> @@ -1069,9 +1070,10 @@ static int de_thread(struct task_struct *tsk) >> return -EAGAIN; >> } >> >> + may_hang = atomic_read(&oldsighand->count) != 1; >> sig->group_exit_task = tsk; >> - sig->notify_count = zap_other_threads(tsk); >> - if (!thread_group_leader(tsk)) >> + sig->notify_count = zap_other_threads(tsk, may_hang ? 1 : -1); > > Eric, this is amazing. So with this patch exec does different things depening > on whether sighand is shared with another CLONE_SIGHAND task or not. To me > this doesn't look sane in any case. It is a 99% solution that makes it possible to talk about and review letting the exec continue after the subthreads are killed but not reaped. Sigh I should have made may_hang say: may_hang = (atomic_read(&oldsignand->count) != 1) && (sig->nr_threads > 1) Which covers all know ways userspace actually uses these clone flags. > And btw zap_other_threads(may_hang == 0) is racy. Either you need tasklist or > exit_notify() should set tsk->exit_state under siglock, otherwise zap() can > return the wrong count. zap_other_thread(tsk, 0) only gets called in the case where we don't care about the return value. It does not get called from fs/exec.c > Finally. This patch creates the nice security hole. Let me modify my test-case > again: > > void *thread(void *arg) > { > ptrace(PTRACE_TRACEME, 0,0,0); > return NULL; > } > > int main(void) > { > int pid = fork(); > > if (!pid) { > pthread_t pt; > pthread_create(&pt, NULL, thread, NULL); > pthread_join(pt, NULL); > execlp(path-to-setuid-binary, args); > } > > sleep(1); > > // Now we can send the signals to setiuid app > kill(pid+1, ANYSIGNAL); > > return 0; > } That is a substantive objection, and something that definitely needs to get fixed. Can you think of anything else? Eric