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 F23D9C18E5A for ; Tue, 10 Mar 2020 20:11:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 911BB215A4 for ; Tue, 10 Mar 2020 20:11:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="m/uY0trW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 911BB215A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 252946B0005; Tue, 10 Mar 2020 16:11:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 203626B0006; Tue, 10 Mar 2020 16:11:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11A4F6B0007; Tue, 10 Mar 2020 16:11:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0049.hostedemail.com [216.40.44.49]) by kanga.kvack.org (Postfix) with ESMTP id EF2016B0005 for ; Tue, 10 Mar 2020 16:11:27 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9DDF2181AEF09 for ; Tue, 10 Mar 2020 20:11:27 +0000 (UTC) X-FDA: 76580547414.23.leg28_cb3c8a7d8426 X-HE-Tag: leg28_cb3c8a7d8426 X-Filterd-Recvd-Size: 6754 Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Mar 2020 20:11:27 +0000 (UTC) Received: by mail-oi1-f196.google.com with SMTP id d63so8457373oig.6 for ; Tue, 10 Mar 2020 13:11:27 -0700 (PDT) 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=K3vOtJHo8wa+L0rub3QWCJZcPdNt+IghtsNXVMZnf9o=; b=m/uY0trWMAr4FqVX9i9CSnmjQPURPHBOvx6pe5fEMWJ/e5Tk2vaRLevTLCVkqDclV/ 9U8dYbHfSmT1VryWEJSOssyM6R8QAQdwr6JjSl1yllVynLdhE+EqANllz3GJD9T5HKJx 5o1mk82fLBEMHb75zYy13h8oqLlVg+LksCTipqO4JL4jJKJTlWmW0OpW3rTbODkp5lQD o6zv+ZZn4FMnxGec2LxSQUD3vMa8YdhAk6f9V4RcuRPJetmizxPCHUgu3hzhD81e8CVo Qx3HgSr4qFdSi9ME0sT7JSnsZUpOvPvCvsVRKmVC565oSKAhwb9Ar6hsa+h/gil57td2 EUFA== 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=K3vOtJHo8wa+L0rub3QWCJZcPdNt+IghtsNXVMZnf9o=; b=FPOEujRhifP4fK/DBLJ8bg3DY5VU02hN8wUxpcrkrz7X1cDQXUx8yVf15Dw65FnPpt 4d/rFAOIEYN5ZPyaXVtK4dg/b+tsBZv2sINaHxwwZd9NExO2R3e+S0OcjmOT89Er2yyp h30Xwg9bqOVcLh92ntn7Yqnqx3kfpod4dVlOlbIZgdEftnnZHoTvSebMD/aWyfS+bqox Uhxv8FTpAMq3p0HS5OHgk4yu28Yrd0Zvd9rUC6s7JJooA9R9apULcQvaojN9NMJvWQHw Ax2TX01X/R0OHqv7Ii9CGZxuWU/IAATWtTQCJmHS0mdf6KM14EzZR0HTrzK87MQeMIRe cGyg== X-Gm-Message-State: ANhLgQ0vjCkdjNN0eA7vXBICbcPnOxcajCrpHHKv+fMBiQcAjWDV0l51 8P/KPx9gboVIG85d7Vx2GRv3P9w72vcQWAu0sFKLNg== X-Google-Smtp-Source: ADFU+vvZVc2KY+6w3Oc3P2SV7qOVRFP8YKpYN4giT8uBe7Bxf6wvbyMTpIifKCNOOu6O6nioDLX4rtyrr5xoVXiS41s= X-Received: by 2002:aca:bac1:: with SMTP id k184mr2032952oif.157.1583871086051; Tue, 10 Mar 2020 13:11:26 -0700 (PDT) MIME-Version: 1.0 References: <87r1y8dqqz.fsf@x220.int.ebiederm.org> <87tv32cxmf.fsf_-_@x220.int.ebiederm.org> <87v9ne5y4y.fsf_-_@x220.int.ebiederm.org> <87eeu25y14.fsf_-_@x220.int.ebiederm.org> <20200309195909.h2lv5uawce5wgryx@wittgenstein> <877dztz415.fsf@x220.int.ebiederm.org> <20200309201729.yk5sd26v4bz4gtou@wittgenstein> <87k13txnig.fsf@x220.int.ebiederm.org> <20200310085540.pztaty2mj62xt2nm@wittgenstein> <87wo7svy96.fsf_-_@x220.int.ebiederm.org> <87k13sui1p.fsf@x220.int.ebiederm.org> In-Reply-To: From: Jann Horn Date: Tue, 10 Mar 2020 21:10:59 +0100 Message-ID: Subject: Re: [PATCH] pidfd: Stop taking cred_guard_mutex To: "Eric W. Biederman" Cc: Christian Brauner , Bernd Edlinger , Kees Cook , 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 , James Morris , 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-api@vger.kernel.org" , Arnd Bergmann , Sargun Dhillon Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 10, 2020 at 9:00 PM Jann Horn wrote: > On Tue, Mar 10, 2020 at 8:29 PM Eric W. Biederman wrote: > > Jann Horn writes: > > > On Tue, Mar 10, 2020 at 7:54 PM Eric W. Biederman wrote: > > >> During exec some file descriptors are closed and the files struct is > > >> unshared. But all of that can happen at other times and it has the > > >> same protections during exec as at ordinary times. So stop taking the > > >> cred_guard_mutex as it is useless. > > >> > > >> Furthermore he cred_guard_mutex is a bad idea because it is deadlock > > >> prone, as it is held in serveral while waiting possibly indefinitely > > >> for userspace to do something. [...] > > > If you make this change, then if this races with execution of a setuid > > > program that afterwards e.g. opens a unix domain socket, an attacker > > > will be able to steal that socket and inject messages into > > > communication with things like DBus. procfs currently has the same > > > race, and that still needs to be fixed, but at least procfs doesn't > > > let you open things like sockets because they don't have a working > > > ->open handler, and it enforces the normal permission check for > > > opening files. > > > > It isn't only exec that can change credentials. Do we need a lock for > > changing credentials? [...] > > If we need a lock around credential change let's design and build that. > > Having a mismatch between what a lock is designed to do, and what > > people use it for can only result in other bugs as people get confused. > > Hmm... what benefits do we get from making it a separate lock? I guess > it would allow us to make it a per-task lock instead of a > signal_struct-wide one? That might be helpful... But actually, isn't the core purpose of the cred_guard_mutex to guard against concurrent credential changes anyway? That's what almost everyone uses it for, and it's in the name...