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 D94B8C46CD2 for ; Mon, 22 Jan 2024 21:30:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B9816B0087; Mon, 22 Jan 2024 16:30:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 66A106B0089; Mon, 22 Jan 2024 16:30:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 531BA6B008A; Mon, 22 Jan 2024 16:30:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 435396B0087 for ; Mon, 22 Jan 2024 16:30:55 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D1986A05C7 for ; Mon, 22 Jan 2024 21:30:54 +0000 (UTC) X-FDA: 81708242028.18.BF7B8E1 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf22.hostedemail.com (Postfix) with ESMTP id E7515C0017 for ; Mon, 22 Jan 2024 21:30:52 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=V0UrQ8pr; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705959053; 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=xKEBr23rbJKu9h7vL24E+EIJQpc/iOsyibRTRHA5Xcc=; b=2ytysBQ6UUHznRgIDNwyR53JvRtqC6ekIC2bO5vhX7lq13+YnVTeuHjeSA9ALZbZjdigV0 1hGLwQVXVziKzXfH3dFWsm4TdqCNFiVzHl/EkDY5QkoZpzFi9gxbTpmwJEYYlpc/5N3jJM NSGk4Hs/isoKWZGu2TrZAib3DdFjmg8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=V0UrQ8pr; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf22.hostedemail.com: domain of keescook@chromium.org designates 209.85.216.51 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705959053; a=rsa-sha256; cv=none; b=xli6FBYs13LyDMi3X9vLp3Y/8b6Fx64e2ws1hsjWuU1n3EGk3rHGWJLnJSZ3G9ozEK7q0V vQdbwDMMaWsKe1FpWz9xszb9Lov+Q4AYDOmdS8sdxX4LoITJQ7DsGUsrKZxmNo2H/LD6Y8 QbhXvQQui9GzvCpxAO7O6vZPLnhmBIE= Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2906dffd8ddso1845948a91.3 for ; Mon, 22 Jan 2024 13:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705959052; x=1706563852; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=xKEBr23rbJKu9h7vL24E+EIJQpc/iOsyibRTRHA5Xcc=; b=V0UrQ8pr1MHgtmt9raCnoi7iVrffCOFiP7givklN4txRgxmEE6QDsK8T6ltmWPrFKI xTefYKKK49wI3eJt/p24xQ8rdPn1uvssLnw7lOIIwV+noPd/q7bIHS7oMzhUUV/8FBXC 2XtIdQrNubb09rx059Cwqlb8XLFLfnGIQQggs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705959052; x=1706563852; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=xKEBr23rbJKu9h7vL24E+EIJQpc/iOsyibRTRHA5Xcc=; b=ct7W/cDwc2aPuJPWCobc8YpgxeWAmQrSRkPuiNF1kAtk4yATpX7RI/hn0WndM1hf37 vsU8jWDaAkNNtiqcLahd/PIhWtKQ+uPuSZSPKDVhHq7G/nGNqOrCKhC9j+ap/b9LTlWS yyIhvFYFbi1HSPjJ9gga4xCyKeXyP0IuJDkWkNWOn0votTK4EZh23BENP5iSU8ztQels 79QX54KOdSBwSbEC/c6jSHu10qBrsJnI3ZIbTd0dCdamCnhe9kvVGnPTtbx7Do3aRs7y pU/ho5hgQXGh4udAsAf0lUxu28SCT6n0DCgcb06ZaD+Gs5XGcZoY0lv4az3dopIelLzH dzWA== X-Gm-Message-State: AOJu0YxUpoVSYyFHO3GCt2AARgizqsUForkBRjUkB/2dE118s3xj5LJm Sr6pdHC4IgUSLOFkTOOI2EswNn0N7SoizVWOUR/v/NP3R43rtsiz+Ha3wZKhWw== X-Google-Smtp-Source: AGHT+IGuu8CRZ67T/sbZ33Kh3Gjp/4gDLn2p+VjWE9BT0X4ASe4DyFux9xBdjaYSy+LIQ61UuJTqIQ== X-Received: by 2002:a17:90b:1093:b0:28f:f706:f276 with SMTP id gj19-20020a17090b109300b0028ff706f276mr2415921pjb.80.1705959051711; Mon, 22 Jan 2024 13:30:51 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id l17-20020a17090a409100b00290ae3bf8d7sm2167130pjg.21.2024.01.22.13.30.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 13:30:51 -0800 (PST) Date: Mon, 22 Jan 2024 13:30:50 -0800 From: Kees Cook To: Bernd Edlinger Cc: Oleg Nesterov , Alexander Viro , Alexey Dobriyan , Andy Lutomirski , Will Drewry , Christian Brauner , Andrew Morton , Michal Hocko , Serge Hallyn , James Morris , Randy Dunlap , Suren Baghdasaryan , Yafang Shao , Helge Deller , "Eric W. Biederman" , Adrian Reber , Thomas Gleixner , Jens Axboe , Alexei Starovoitov , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-kselftest@vger.kernel.org, linux-mm@kvack.org, tiozhang , Luis Chamberlain , "Paulo Alcantara (SUSE)" , Sergey Senozhatsky , Frederic Weisbecker , YueHaibing , Paul Moore , Aleksa Sarai , Stefan Roesch , Chao Yu , xu xin , Jeff Layton , Jan Kara , David Hildenbrand , Dave Chinner , Shuah Khan , Zheng Yejian , Elena Reshetova , David Windsor , Mateusz Guzik , Ard Biesheuvel , "Joel Fernandes (Google)" , "Matthew Wilcox (Oracle)" , Hans Liljestrand Subject: Re: [PATCH v14] exec: Fix dead-lock in de_thread with ptrace_attach Message-ID: <202401221328.5E7A82C32@keescook> References: <20240116152210.GA12342@redhat.com> <20240117163739.GA32526@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E7515C0017 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 431435azod3rs7c86cijk9n5fuitkyor X-HE-Tag: 1705959052-618540 X-HE-Meta: U2FsdGVkX184vPGN8Li4ZlQCf/LQKOgq692VCgq3K4iyJJdk2N6ZJLVDIJ34/zRcGMwiMS6uiAazBJiNPLPhfKIufJ2ruPlZmNIoJ5hiI88Fq6jcL14ywVitYcxOrsySH0cJpoG8YNSE2nCMdV49hpNLUXbt4d7CMKPjDgSWlMKXb6zTkmWEBBkJRvoLl91MLo9HBkhvhpNHbflPXtX6msqEzA8mcVgWiA47L5aCxBXB/X/7dBqw22/FkoGttNcKp/CKU970ExBi04iIQF6x5KE5qN0vNWO1avzMqolZFCXlfYCVFg+cUePDkXMmKjoDtR8f9W58N2Z5gAUaZtrGasdGAugjJvu8+PU5sH/sn1z9veIa2cTalneX2duUpE/vgGVep0KvmPTH9HkKVx1yed67UDUbGMZ5uK7NMPHLJWCCDxigeO0YpGQHht8uKRovn2mL+HVdahZ5GhX8twm+S7G6MfBDP3fY4AYLdJbacnVce5iDQkmNX4QwqNDgNdm6IgVAEyiOpeu+B64Xz5jb2gqgGT8V3ffjHOScVRRBJDpsV8ns2QWZm5u7F7q4qBbE6pygoPxlmFMUok8YeRUl93Qx56wSqSdDNa87BzA0VtZsiAHGGH/rIFz+h1v6aJgONRPRrGyJnQGLW1O6ldcgxxLhWLIDjsJ+IeiQ+dWfoeQu3UtPkAivEdSZ3mmzSmyoLnuqK2p9UB0wgpOXYs82RGAdo+YkQtsomvQoIaD7Wi5dZBFknlkdQBEMGibx78jw1f4XejW2LXH1d8v8LBLqB72MsBNR+w1wYQ9beoEAKBlr1OE3AzG2q4HtYPPKN4tkfDsuQNJ8d+qpT11jqSZ9GJcR8IjI+4exdSrVSRC8EkjVnqvfLBuC/XaHqTjYzNVqXDZFpyuu/qFQEN29l7syHAtHdZBi74VyxUFeBipQfI6TYoI9s3NWoPpT6vEb1SG03UxgYEXenBK5aZ71gCw IOEMcAsD kAB50a3OV4BfVzrubCuKfhcti6jc+58tR/lT5rAWu2/YPwK2fvUhw8m5TUQBWNl5qzlUHlmIWfPFxTTyFGPsP5bb2/PNnPr3BSnn1xGJ8amBSXpDXofI7aJH5wF4m2Tcz/HFJ4Xctn00f8m02UwmjhqUYZjLC7IvurJAQpA7yyPNwkTORC45R7CfvmYtbtfWKdgmKbVoHXcRecLDuGLYg6QPTlZwu7HSMKx/cGo7Pkk6bqlglnVeS6E7iPXHkNN8hOTtM/jfJI8ZLtw3HxButm59dwsiDYip1gAKCcQAJTtDlSDJqdNL1pPwxR7zUcVU+WKfmUIj4YZnWO7C7FrzOYFsQzot3bkmp5hJCFJd7QwuNXoNM3yL6cs/TAPrFdLZ7gcz7wHBnVH8gcDeZV4Gyefn2P5L7A6Iqwh5xxtK8DA3vdxR32Z1b3fkyAGLUG39r60US+vrcmUSP9TkiJE1HDg3lr1r8ak16HlWR7gMnGtGPUk7DyA8Kp4sCHMkLE+tgcpEn 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: List-Subscribe: List-Unsubscribe: On Mon, Jan 22, 2024 at 02:24:37PM +0100, Bernd Edlinger wrote: > The main concern was when a set-suid program is executed by execve. > Then it makes a difference if the current thread is traced before the > execve or not. That means if the current thread is already traced, > the decision, which credentials will be used is different than otherwise. > > So currently there are two possbilities, either the trace happens > before the execve, and the suid-bit will be ignored, or the trace > happens after the execve, but it is checked that the now potentially > more privileged credentials allow the tracer to proceed. > > With this patch we will have a third prossibility, that is in order > to avoid the possible dead-lock we allow the suid-bit to take effect, > but only if the tracer's privileges allow both to attach the current > credentials and the new credentials. But I would only do that as > a last resort, to avoid the possible dead-lock, and not unless a dead-lock > is really expected to happen. Instead of doing this special cred check (which I am worried could become fragile -- I'd prefer all privilege checks happen in the same place and in the same way...), could we just fail the ptrace_attach of the execve? -- Kees Cook