From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-8faf.mail.infomaniak.ch (smtp-8faf.mail.infomaniak.ch [83.166.143.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13BC317E906; Wed, 17 Jul 2024 10:01:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=83.166.143.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721210476; cv=none; b=EYLR4VyLD2Ma1KxR2V9uUnmq3N012/IXxCvYCZCNtUdEBsPHeiC8pjyKVNOUPqcJ9uiQwsX37e+51NMMDjdfUncEcC1bOMJP5Hgv+ayzTXnx0j9kjJ2txMAmuRrh4KS9HywDH3+bgyhCjcvP4WINN1rX3g/M78i2xhIX21Zlw+4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721210476; c=relaxed/simple; bh=BUgvKjy/bDgc1rPb0S+QGNTxH79dHOZQL5vWrkXMlZU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kGL1QIZOCRQZtJ+fQKKQDhBhoIVFtLuVioBX06odXK5kX5fR0SVRK1g5VgbTP1MtZUyjBaCKa+BZmxwh1um35/qIOq3At7KZhiRLF8x+CkbmSRxsryPGWIsju1QRmiWkr4rFra7lkf9x4nak306i15+72sp7Cnhv7nquj+SgkQk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net; spf=pass smtp.mailfrom=digikod.net; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b=CQORCJnW; arc=none smtp.client-ip=83.166.143.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=digikod.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=digikod.net header.i=@digikod.net header.b="CQORCJnW" Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4WPBK51MCSz12fy; Wed, 17 Jul 2024 12:00:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1721210457; bh=at7t7jmIJKXHqGUzpxK1Wf9lPPVRXO39/lqkd8lIEAw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CQORCJnW9yxbTKj6mpI9aiBiMIEPVkQXXIIrp+otWT6xL5ADv7F3xuWrpM86OT8mj hxlEfQUIBU/baLZgKf0q2vx1f1bXbKAEwuiDwGfKxEwyKsnS9Qmdbrtw5MgdJ14FOt uuNl6eAnPl03pzjKcgwZGEmBQDmghsV46Q7k+5KU= Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4WPBK0119bzLGN; Wed, 17 Jul 2024 12:00:52 +0200 (CEST) Date: Wed, 17 Jul 2024 12:00:49 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Steve Dower Cc: Jeff Xu , Al Viro , Christian Brauner , Kees Cook , Linus Torvalds , Paul Moore , Theodore Ts'o , Alejandro Colomar , Aleksa Sarai , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Christian Heimes , Dmitry Vyukov , Eric Biggers , Eric Chiang , Fan Wu , Florian Weimer , Geert Uytterhoeven , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Jordan R Abrahams , Lakshmi Ramasubramanian , Luca Boccassi , Luis Chamberlain , "Madhavan T . Venkataraman" , Matt Bobrowski , Matthew Garrett , Matthew Wilcox , Miklos Szeredi , Mimi Zohar , Nicolas Bouchinet , Scott Shell , Shuah Khan , Stephen Rothwell , Steve Grubb , Thibaut Sautereau , Vincent Strubel , Xiaoming Ni , Yin Fengwei , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2) Message-ID: <20240717.AGh2shahc9ee@digikod.net> References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Infomaniak-Routing: alpha On Wed, Jul 17, 2024 at 09:26:22AM +0100, Steve Dower wrote: > On 17/07/2024 07:33, Jeff Xu wrote: > > Consider those cases: I think: > > a> relying purely on userspace for enforcement does't seem to be > > effective, e.g. it is trivial to call open(), then mmap() it into > > executable memory. > > If there's a way to do this without running executable code that had to pass > a previous execveat() check, then yeah, it's not effective (e.g. a Python > interpreter that *doesn't* enforce execveat() is a trivial way to do it). > > Once arbitrary code is running, all bets are off. So long as all arbitrary > code is being checked itself, it's allowed to do things that would bypass > later checks (and it's up to whoever audited it in the first place to > prevent this by not giving it the special mark that allows it to pass the > check). Exactly. As explained in the patches, one crucial prerequisite is that the executable code is trusted, and the system must provide integrity guarantees. We cannot do anything without that. This patches series is a building block to fix a blind spot on Linux systems to be able to fully control executability.