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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A95FC433FE for ; Fri, 7 Oct 2022 01:41:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE9F36B0072; Thu, 6 Oct 2022 21:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E99746B0073; Thu, 6 Oct 2022 21:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3A026B0074; Thu, 6 Oct 2022 21:41:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C1BD46B0072 for ; Thu, 6 Oct 2022 21:41:21 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 97BC614135E for ; Fri, 7 Oct 2022 01:41:21 +0000 (UTC) X-FDA: 79992450762.27.DC20ED4 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf16.hostedemail.com (Postfix) with ESMTP id 28D5C180011 for ; Fri, 7 Oct 2022 01:41:19 +0000 (UTC) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 2971ecnl032685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Oct 2022 21:40:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1665106847; bh=qaGXQZPJ+DMM6m33/wU4mECLmQpjFLtDJn6CdcOWtKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KSalaJnH4Pyw9am3lmnE824Wr2kBhNth9uCO4mXO5AzKtequoJLzjonneUAC8ZhxR 4Hz1eaUw7xthlsGZIvbrKDmeqfMsaZL0mX9jE1bwkYelTLIujVkzCQre3la+eHpRvk jehUy8nGH756ojGWF+Lya0ILI+OcQWLFjLYpTrHqGQ5P8VsLDrkkyMAy5y7ZgOktww VOQvAZIroJGMqt4qSIuhel3Tn9O/0JEpicFLNkngkAJ7T5kP6qkzL5z4U+3ELVIhC1 z6ZBz5xcg7Vu7b4LWp9pQf8jyIsi6uPKcXUiiBI32krkxUNWm4c1/xFR2R+71IKcQi mHXaABEZ7m0DA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id C2CF515C35F2; Thu, 6 Oct 2022 21:40:38 -0400 (EDT) Date: Thu, 6 Oct 2022 21:40:38 -0400 From: "Theodore Ts'o" To: Kees Cook Cc: Jorge Merlino , Christian Brauner , Eric Biederman , Jann Horn , Alexander Viro , Thomas Gleixner , Andy Lutomirski , Sebastian Andrzej Siewior , Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, John Johansen , Paul Moore , James Morris , "Serge E. Hallyn" , Stephen Smalley , Eric Paris , Richard Haines , Casey Schaufler , Xin Long , "David S. Miller" , Todd Kjos , Ondrej Mosnacek , Prashanth Prahlad , Micah Morton , Fenghua Yu , Andrei Vagin , linux-kernel@vger.kernel.org, apparmor@lists.ubuntu.com, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH] Fix race condition when exec'ing setuid files Message-ID: References: <202209131456.76A13BC5E4@keescook> <202210061301.207A20C8E5@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202210061301.207A20C8E5@keescook> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665106880; a=rsa-sha256; cv=none; b=mMIpqiDHmjkXIwM6JwoZVgANOF9mJlx1xkIgqVahlP09iRReB3GU3sblAfgEexYw/kzexB E+Jirhbes6uisnpNG6A1l/gfcRNhcAOUXwq+FVgcZJ1spmF9tksNLc+OTuILdTpwv2RUrc 9Azx5QnEFWCqGGiZzCFnJRZz7dr40Bs= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=KSalaJnH; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665106880; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qaGXQZPJ+DMM6m33/wU4mECLmQpjFLtDJn6CdcOWtKQ=; b=vnb/5Xd0i3mZAhAwia7M8gCyzEXhw38fwy16JZFNVPMiTOwpUkObEhe7s6j5XTfB0nDRsw gKwidayt1W8zzA7BcZpewrS0uRCvIQeaMfhHUEKk/DF4Gzevh2YljnONt6c/60fVmZs53g JLmg5sZOjctgH0Y2G8EFd0jnXLJl+KM= X-Rspamd-Queue-Id: 28D5C180011 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=KSalaJnH; spf=pass (imf16.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu X-Stat-Signature: qk6ctznwgnuzpghscqhqei4y44zi44yb X-Rspamd-Server: rspam04 X-HE-Tag: 1665106879-714218 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 Thu, Oct 06, 2022 at 01:20:35PM -0700, Kees Cook wrote: > > So the question, then, is "why are they trying to exec while actively > spawning new threads?" That appears to be the core problem here, and as > far as I can tell, the kernel has behaved this way for a very long time. > I don't think the kernel should fix this, either, because it leads to a > very weird state for userspace, where the thread spawner may suddenly > die due to the exec happening in another thread. This really looks like > something userspace needs to handle correctly (i.e. don't try to exec > while actively spawning threads). One of the classic failure modes is when a threaded program calls a library, and that library might try to do a fork/exec (or call system(3) to run some command. e.g., such as running "lvm create ..." or to spawn some kind of helper daemon. There are a number of stack overflow questions about this, and there are some solutions to _some_ of the problems, such as using pthread_atfork(), and knowing that you are about to call fork/exec, and use some out of band mechanism to to make sure no threads get spawned until the fork/exec is completed --- but if you don't know that a library is going to do a fork/exec, well, life is tough. One technique even advocated by a stack overflow article is "avoid using threads whenver possible". :-/ - Ted