From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4250C3F2D8 for ; Mon, 2 Mar 2020 18:08:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A207A2465E for ; Mon, 2 Mar 2020 18:08:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="UqoUm420" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727706AbgCBSI6 (ORCPT ); Mon, 2 Mar 2020 13:08:58 -0500 Received: from mail-oi1-f196.google.com ([209.85.167.196]:44787 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727470AbgCBSI5 (ORCPT ); Mon, 2 Mar 2020 13:08:57 -0500 Received: by mail-oi1-f196.google.com with SMTP id d62so103101oia.11 for ; Mon, 02 Mar 2020 10:08:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PzpHTT1CytF1CxOEOyrFfNGNhtkDEaDUtrYOH2iFLfA=; b=UqoUm420YQqph3lafHzahQC9V4PdPL/4Qyv6M+TEFjDDlhJUhALb/SAIvAmoSGffyg a+snzgE9CJkyJGW23tqeS/3KQPZf8xJ7BanaVOsbMgKmsVis3fA3OOYQ4v4jTJ1AGhBx K9uQcOSkDeBAtHH7P5nmgTAOojjqNLiO2lPI2fA3RN3wz4dmhavt79Zq4NlnBzpJ+OiA y/TbZNOouXWb/oNa3vM1C3IKrlLfcmIRapwpat4xfLEuvxXctHbiwYexiaQCCtswST76 0aZ+VZ+Y0oTlg6eIsuwolOfq1+Y8oOzdLvBO6TZUDoqbSO/q1tj2btepq92gHR5lOUfD s1FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PzpHTT1CytF1CxOEOyrFfNGNhtkDEaDUtrYOH2iFLfA=; b=DAjWgYEfb08TdMhulMh0UK0KaRmOeMA3HGiKctS2d+vdhLPkTWEARh/dCRBqQf57RM RJme3pFdM1g+SK/1ng2IrlJkFWpEvTrhgmpnUFjdIwq0vVESo04ndEZoprU1bxwVFz6F RkfovzbQ388cPQbbTlwokNHstr2fn7VpsWAkGJKkW0saT385bQhzuyNJ6BBg4qhNQ7gy b7TF4ZGyfeyK3duCbiJX/W9Zl4f4MPNS0e+w/RzSIlIr4KlTMdamt38UoOU0Q70VeNEZ EDMuu/XWgSKbxSBXKQGHkBsn3j3E2CWyKskhQtvXUbS37Gqt+b4hX4lbBZZDfcy7WBfE LFiw== X-Gm-Message-State: ANhLgQ2jv0+VsML6a+sXre41aN17nC3A9U/421OM6Z6q1Utk4x0d8rYZ GFSUZgBMbQG9UU2jcz/HpHtm22Qbv02p/r5NeIDr+w== X-Google-Smtp-Source: ADFU+vvElPHbaOkc/ffKR7JWZMzjpg6bZ6JiSaTN3SNT/Yuy1ZmDiKrsYKSVrGwdXREPaOYmbN9ESv+hvKDnpyK2MgA= X-Received: by 2002:aca:538e:: with SMTP id h136mr242942oib.39.1583172536153; Mon, 02 Mar 2020 10:08:56 -0800 (PST) MIME-Version: 1.0 References: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> <87a74zmfc9.fsf@x220.int.ebiederm.org> <87k142lpfz.fsf@x220.int.ebiederm.org> <875zfmloir.fsf@x220.int.ebiederm.org> <5e5d45a3.1c69fb81.f99ac.0806@mx.google.com> In-Reply-To: <5e5d45a3.1c69fb81.f99ac.0806@mx.google.com> From: Jann Horn Date: Mon, 2 Mar 2020 19:08:29 +0100 Message-ID: Subject: Re: [PATCHv2] exec: Fix a deadlock in ptrace To: Christian Brauner Cc: Bernd Edlinger , "Eric W. Biederman" , James Morris , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , Kees Cook , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , linux-doc@vger.kernel.org, "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "stable@vger.kernel.org" , linux-security-module Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 2, 2020 at 6:43 PM wrote: > On March 2, 2020 6:37:27 PM GMT+01:00, Jann Horn wrote: > >On Mon, Mar 2, 2020 at 6:01 PM Bernd Edlinger > > wrote: > >> On 3/2/20 5:43 PM, Jann Horn wrote: > >> > On Mon, Mar 2, 2020 at 5:19 PM Eric W. Biederman > > wrote: [...] > >> >> I am 99% convinced that the fix is to move cred_guard_mutex down. > >> > > >> > "move cred_guard_mutex down" as in "take it once we've already set > >up > >> > the new process, past the point of no return"? > >> > > >> >> Then right after we take cred_guard_mutex do: > >> >> if (ptraced) { > >> >> use_original_creds(); > >> >> } > >> >> > >> >> And call it a day. > >> >> > >> >> The details suck but I am 99% certain that would solve everyones > >> >> problems, and not be too bad to audit either. > >> > > >> > Ah, hmm, that sounds like it'll work fine at least when no LSMs are > >involved. > >> > > >> > SELinux normally doesn't do the execution-degrading thing, it just > >> > blocks the execution completely - see their > >selinux_bprm_set_creds() > >> > hook. So I think they'd still need to set some state on the task > >that > >> > says "we're currently in the middle of an execution where the > >target > >> > task will run in context X", and then check against that in the > >> > ptrace_may_access hook. Or I suppose they could just kill the task > >> > near the end of execve, although that'd be kinda ugly. > >> > > >> > >> We have current->in_execve for that, right? > >> I think when the cred_guard_mutex is taken only in the critical > >section, > >> then PTRACE_ATTACH could take the guard_mutex, and look at > >current->in_execve, > >> and just return -EAGAIN in that case, right, everybody happy :) > > > >It's probably going to mean that things like strace will just randomly > >fail to attach to processes if they happen to be in the middle of > >execve... but I guess that works? > > That sounds like an acceptable outcome. > We can at least risk it and if we regress > revert or come up with the more complex > solution suggested in another mail here? Yeah, sounds reasonable, I guess.