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 1F526C3F2D1 for ; Sun, 1 Mar 2020 20:00:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E89C02083E for ; Sun, 1 Mar 2020 20:00:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="geEqLlC1" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726188AbgCAUAu (ORCPT ); Sun, 1 Mar 2020 15:00:50 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:42191 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725895AbgCAUAu (ORCPT ); Sun, 1 Mar 2020 15:00:50 -0500 Received: by mail-ot1-f66.google.com with SMTP id 66so7614951otd.9 for ; Sun, 01 Mar 2020 12:00:49 -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=eSJCogFW+5WEfqSVoqYuW5WPipQ09ya4rXn8XpVI9lk=; b=geEqLlC1SOE3TSZPMu4eY2C7kEQ3iAEu8+MjDZth1yJJEz3aYIl8RZzNGqXKo+fdBK L3piqmGBZ+R6u2jb71FG+otXTb5dexaFNTIMqfdFtBwyUv8J83uWWiWpJL700olDe1KU jdQ95KSTEviW1p++P8rmN10buW8MUjs1Ce5bxgvibleP8FVy2pIqdkf+iVbKv0OxIfep R3lnoXwspaouzFJKvOL2TU0Ri+Z9X4sJEOZJahs/nnjs5Uj7mCy6y8dFFjwiRQtUui/3 PYeYJCJjLDd5jpik81hu7laW8Arud8MEejgRzp/E94E5OSXDgeoA9nO6m2RJMQ1ob9wA F/aQ== 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=eSJCogFW+5WEfqSVoqYuW5WPipQ09ya4rXn8XpVI9lk=; b=FMF+xyqvBA/mLPaoWZAY5Nk+lA3cMw0ZfUOtw/FFmEufp5xDlf895UCan8b3ujvgF0 k1MxKZ/uIxWhWT00FFZ8E7pc7x33Jk6sxD8g0/m6h7b7qIiZThfZhBI707+osfIAHmzt nVra3fTr7ZAvTBipSvrreyqqfWV0as5/XKaLt/NqKD0pkMRKZGMJp1Ec63mhwOAf4bHJ KVVnvS/vS95iRllYGYAM6jSaSeTGZmh/VbHVOc4dogI4Nuq3AacJ09cnoV14mYtgz+iZ BN5tE7eYQAZCJOuRBlEyj2jOPE1wLnexfTA6tNP13JAFM1AaHc5HPeA7Woosbr57E6lZ scvA== X-Gm-Message-State: APjAAAVPZ+UxP0+3fhfxsb4PIHS4V+QO3yu961qkvoT951vtHQcnJXpM ZBH4g6AORkWK6AkNDuc/+JaUqN6hZeRaI+rcaY/jsw== X-Google-Smtp-Source: APXvYqxlPmGGj6lqZ/+U20/sqfXaMGOTkoLMW6nyRqaPvY8us5RwnrwLaHiGmuMsLhOUI/kEd8nfooddFe4/2Iz0+l8= X-Received: by 2002:a9d:5e8b:: with SMTP id f11mr10976903otl.110.1583092849244; Sun, 01 Mar 2020 12:00:49 -0800 (PST) MIME-Version: 1.0 References: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> In-Reply-To: <20200301185244.zkofjus6xtgkx4s3@wittgenstein> From: Jann Horn Date: Sun, 1 Mar 2020 21:00:22 +0100 Message-ID: Subject: Re: [PATCH] exec: Fix a deadlock in ptrace To: Christian Brauner Cc: Bernd Edlinger , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , "Eric W. Biederman" , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra (Intel)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , 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" Content-Type: text/plain; charset="UTF-8" Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Sun, Mar 1, 2020 at 7:52 PM Christian Brauner wrote: > On Sun, Mar 01, 2020 at 07:21:03PM +0100, Jann Horn wrote: > > On Sun, Mar 1, 2020 at 12:27 PM Bernd Edlinger > > wrote: > > > The proposed solution is to have a second mutex that is > > > used in mm_access, so it is allowed to continue while the > > > dying threads are not yet terminated. > > > > Just for context: When I proposed something similar back in 2016, > > https://lore.kernel.org/linux-fsdevel/20161102181806.GB1112@redhat.com/ > > was the resulting discussion thread. At least back then, I looked > > through the various existing users of cred_guard_mutex, and the only > > places that couldn't be converted to the new second mutex were > > PTRACE_ATTACH and SECCOMP_FILTER_FLAG_TSYNC. > > > > > > The ideal solution would IMO be something like this: Decide what the > > new task's credentials should be *before* reaching de_thread(), > > install them into a second cred* on the task (together with the new > > dumpability), drop the cred_guard_mutex, and let ptrace_may_access() > > check against both. After that, some further restructuring might even > > Hm, so essentially a private ptrace_access_cred member in task_struct? And a second dumpability field, because that changes together with the creds during execve. (Btw, currently the dumpability is in the mm_struct, but that's kinda wrong. The mm_struct is removed from a task on exit while access checks can still be performed against it, and currently ptrace_may_access() just lets the access go through in that case, which weakens the protection offered by PR_SET_DUMPABLE when used for security purposes. I think it ought to be moved over into the task_struct.) > That would presumably also involve altering various LSM hooks to look at > ptrace_access_cred. When I tried to implement this in the past, I changed the LSM hook to take the target task's cred* as an argument, and then called the LSM hook twice from ptrace_may_access(). IIRC having the target task's creds as an argument works for almost all the LSMs, with the exception of Yama, which doesn't really care about the target task's creds, so you have to pass in both the task_struct* and the cred*.