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 9F061C3DA7F for ; Mon, 5 Aug 2024 15:35:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ADDD6B00BA; Mon, 5 Aug 2024 11:35:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 252C26B00BB; Mon, 5 Aug 2024 11:35:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F4216B00BC; Mon, 5 Aug 2024 11:35:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E1C7F6B00BA for ; Mon, 5 Aug 2024 11:35:46 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 83A2A40389 for ; Mon, 5 Aug 2024 15:35:46 +0000 (UTC) X-FDA: 82418591892.20.9132581 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf25.hostedemail.com (Postfix) with ESMTP id 7A298A0010 for ; Mon, 5 Aug 2024 15:35:44 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KpdLnMIv; spf=pass (imf25.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722872063; 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=G1/LRYRemURQfaKrFaMwLXhTXmU7+p6Y5XW0eXRyh8E=; b=cYl3iF42fkLkLixcH4+rwUnva1nOet/1GwBXUEQuo3lkG0uCvb2ZDy8vDDJKPlSM0C/W73 +kLz63vqPL2hUzJUHphkrVmwUhTPW1KOdPNUhdNdwocigzXDbByDlFiBjR1d9O4/pxlipz 0mrkRfempO3x8CFuLuIgJlpcQs3dpR8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KpdLnMIv; spf=pass (imf25.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722872063; a=rsa-sha256; cv=none; b=U0X7BVMAvvBgXH2Rru1gLEBcRZsFOwmx6IZc0xquACPiV+dGAT71k+MSQJavdYG+ZPseP1 g28g6/RTdvaaCHpp60bz1NYgk1SBwBXNCpGVblo0fyCiaeriHqAG9XttOJW0nATY7xgVdH axoCmQXfcHQGgT/5wXlyzcGTAxfIR1c= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 6EB25CE0A15; Mon, 5 Aug 2024 15:35:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BC12C32782; Mon, 5 Aug 2024 15:35:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722872140; bh=fW0hqKtwItjdTsBb9Y5QYMsGWy4TX25zlp03368880A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KpdLnMIvrnE2kazr1tCu9bKLFuGYeeRMrtD73Xdc6nQW75Jvm4MF7uzZWjHHKmCnX 4+NabMXLV+wUtNH2C1kCkjOqQ0OuDBTP6pWT4E1wEfHFNlmzExwevc0kwtOLXIMVMY LbZqLyjFDQ1w5DAbmh877L3DewSs44SsqmeMxSV3zMr0Y0UMyAEhTHkT0OWkQH0a80 i7FD0Y2nudS1iB1l+CMwt8mWzzow82Vsw1b9Ng0yhNlH938Ep6yIfuKm86Dz2qpEYd FRATcEn2EEIFgvIcC/0EDzTnTWVBrHBBMhY8/1mbASLDAGsNIbNAEl99/xf8oKHtJe zW0u32xD8Oz/Q== Date: Mon, 5 Aug 2024 17:35:35 +0200 From: Christian Brauner To: Mateusz Guzik Cc: viro@zeniv.linux.org.uk, jack@suse.cz, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, josef@toxicpanda.com, wojciech.gladysz@infogain.com, ebiederm@xmission.com, kees@kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] exec: drop a racy path_noexec check Message-ID: <20240805-denkspiel-unruhen-c0ec00f5d370@brauner> References: <20240805-fehlbesetzung-nilpferd-1ed58783ad4d@brauner> <20240805131721.765484-1-mjguzik@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240805131721.765484-1-mjguzik@gmail.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 7A298A0010 X-Stat-Signature: fjbdb6btjr35gdguqkommfeoxghnjzos X-Rspam-User: X-HE-Tag: 1722872144-465995 X-HE-Meta: U2FsdGVkX18VqRmvOZKP4LxcTzsAjP9M0acIIXNtZ+cD/9jVzHlwRxna70VMof4Ay5mi8gna5bA8YNo80heycTZNtwOGRvqJol6LUDm+F/6SDL0XPefmm7Njr+/y1Ji9ovuxWEV7sleUATmzazhqZMaLWNZ/KIVBjM7yFRIngGuR+lOZH1y4lErM2qJRuQnE20vKqaHqdCjmKc/HuwJg7qMfpRGCpB70yGEMDRSaMugFc2Oocb9ntn+EPw4mA/MfhwhVe69RDwrcBwoSzNbccBQ1BgGX+V5iHjOd3uYpl1debd+xNCnAmDwkJWTas3OfgZrJJ2GJYgMV2Vl0EtAnXYssDtbVfHDOiesh7xBNVcgRCEjJgG4z2D5fd0XWALW3+3JkZK502DbR67oNNPp6id/J74HiakX/LnPGIOFh1qyKJzZeW5iCn+BpsjMQShfw7xPGElasJzcO0kwx41qVK+pmb4hBtHBR5WHiJ7YLoXVPiPrtX0aU/mTCx/IMn4fU6ijmINlL8x6W3b1ctJs1xQrDHA+yz2y/riKueCS/wds2LcaySg+nPdUPjTJ9TBAaoV5xfTGmkdmhqKJ49mBzypx24u+dQ38jw/J7lOBq9t84BW2GA1fkUosfRl98hJMgQowTjuxDcYKnp4d1lHvXqtMTe8F0hVGsXPZTCWqvxqQ4oglb8c31qU/0MBjYJf1Ipa7Jjx/6hT0M7HfvShfe6WNJgRCxbT2gnkN+b2cWAsjT+hBrOI4c3px5O3RTpkNvUo5K92CPIpES+eoez5M67nxZKvHkIHOCP5PPVana6OFOQT2ik7ra57x5ZC0m0eaa8Kw+XnE4AAQiTD5l8xZD7NLLXZjDamDm+HMNUCk6qGHlhloi1QTfVaRtHEdKqCTDkapMfN8TSv01Gs1qbi+vrkgJfJUX1fSyCBggLv1MaIP+Rei1wPPyu3yCUOPmpTEmZskx/E+MePbznCnFn95 vhfSQOfE UYes+e3yzhWiKcWxaLAX6NTytwO9ZUqe/HfJQjG9jC7Y293pPNezbdnNhJ82aix/nJWg2IbzAXvwFBMtqLWg60FXW8R1biCUWXPNOkLAEPTkdP1jMS9bTSe8afT7xXp4TpaqnR4NNpfl6RrJauSWC2rEiPydtjYUmkFblBhb1DLg3Pom31MfENrElzGaYBtYWTO77ZrnL7ihPz89lLiAsG77tnqs/luucMbWhvh/P+q7O+Rk8+GEhWi8IRunI6GHUpM3tAkzDO4zRJWntrExPt84l0csFMxhMzk4J30LWDKQEc+tShyWll8cFOWjXuZM3WzzX X-Bogosity: Ham, tests=bogofilter, spamicity=0.018726, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > To my reading that path_noexec is still there only for debug, not > because of any security need. I don't think it's there for debug. I think that WARN_ON_ONCE() is based on the assumption that the mount properties can't change. IOW, someone must've thought that somehow stable mount properties are guaranteed after may_open() irrespective of how the file was opened. And in that sense they thought they might actually catch a bug. But originally it did serve a purpose... > > To that end just I propose just whacking it. ... the full history (afaict) is that once upon a time noexec and whether it was a regular file were checked in (precurors to) inode_permission(). It then got moved into the callers. The callers also called may_open() directly afterwards. So the noexec and i_mode check preceeded the call to may_open() and thus to inode_permission(). Then may_open() got moved into the open helpers but the noexec and i_mode checks stayed behind. So the order was now reversed. That in turn meant it was possible to see non-regular file exec requests in security_inode_permission(). So the order was restored by moving that check into may_open(). At that time it would've made sense to also wipe the path_noexec() from there. But having it in there isn't wrong. In procfs permission/eligibility checks often are checked as close to the open as possible. Worst case it's something similar here. But it's certainly wrong to splat about it.