From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0b.mail.infomaniak.ch (smtp-bc0b.mail.infomaniak.ch [45.157.188.11]) (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 1FCBB16A92D for ; Fri, 5 Jul 2024 17:54:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720202067; cv=none; b=bvsU5E+6SO7b3NZWCkhr/rz8sMbit0+s0pCs7Pd6h/JI1BoP+JEZWQrK57Pu041XQUHLjdTLK6/mZ8QKcnmHs57bD8FujroBPjSqsG3BSaDev7iZUWwvFFCIrj3QHOynaZSJuTJM0t7+t8d+cElf5UOKTQxTFNh+zwiTBn+2fBE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720202067; c=relaxed/simple; bh=CDELy0u12/apheW6IeTbXBNZRgy3vhqtkFH51+o5e8E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gdWTRaZkX0uxYryQLXBpiJ7UjEwVm6y7dkZ6z6S5BhDti5A4wktVpttuidqt9c0PfMQfSYPFmBGcBq+f4/jK1CdKRFfCu+iZyjcxNl1yIpWL/XZxJZghM2Dv75sk4NJSXzsJsMkxuYI8UPGifaV8No00hve3oNECEtnyMsDMncw= 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=Uz05dbe7; arc=none smtp.client-ip=45.157.188.11 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="Uz05dbe7" Received: from smtp-4-0001.mail.infomaniak.ch (smtp-4-0001.mail.infomaniak.ch [10.7.10.108]) by smtp-4-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4WG1Nt0T13zRyL; Fri, 5 Jul 2024 19:54:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1720202061; bh=6nsQl2eLVsfJqAkYOl2Q8wRXDEXx0pOL2pfLfb7tTMo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Uz05dbe7Ob59tAGgoZ5Yjo6Tz5LISGDzXwJzQQmXaIWdnEEvfxibNtD4yptwf9qtz X9SeQWL6U73YIqYx3mjObKAoBQuXFpzZjr3gTfhRYFoNFE5KMnq/nLAcU71rq1XGkq ZFDlzrBMjaVD+zLeDHPNyvdSB5mHYY5rp1r7ybT0= Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4WG1Nq1HBXzkwK; Fri, 5 Jul 2024 19:54:19 +0200 (CEST) Date: Fri, 5 Jul 2024 19:54:16 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Kees Cook Cc: Al Viro , Christian Brauner , 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 , Jeff Xu , 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 Dower , 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 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits Message-ID: <20240705.IeTheequ7Ooj@digikod.net> References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-3-mic@digikod.net> <202407041711.B7CD16B2@keescook> Precedence: bulk X-Mailing-List: linux-security-module@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202407041711.B7CD16B2@keescook> X-Infomaniak-Routing: alpha On Thu, Jul 04, 2024 at 05:18:04PM -0700, Kees Cook wrote: > On Thu, Jul 04, 2024 at 09:01:34PM +0200, Mickaël Salaün wrote: > > Such a secure environment can be achieved with an appropriate access > > control policy (e.g. mount's noexec option, file access rights, LSM > > configuration) and an enlighten ld.so checking that libraries are > > allowed for execution e.g., to protect against illegitimate use of > > LD_PRELOAD. > > > > Scripts may need some changes to deal with untrusted data (e.g. stdin, > > environment variables), but that is outside the scope of the kernel. > > If the threat model includes an attacker sitting at a shell prompt, we > need to be very careful about how process perform enforcement. E.g. even > on a locked down system, if an attacker has access to LD_PRELOAD or a LD_PRELOAD should be OK once ld.so will be patched to check the libraries. We can still imagine a debug library used to bypass security checks, but in this case the issue would be that this library is executable in the first place. > seccomp wrapper (which you both mention here), it would be possible to > run commands where the resulting process is tricked into thinking it > doesn't have the bits set. As explained in the UAPI comments, all parent processes need to be trusted. This meeans that their code is trusted, their seccomp filters are trusted, and that they are patched, if needed, to check file executability. > > But this would be exactly true for calling execveat(): LD_PRELOAD or > seccomp policy could have it just return 0. If an attacker is allowed/able to load an arbitrary seccomp filter on a process, we cannot trust this process. > > While I like AT_CHECK, I do wonder if it's better to do the checks via > open(), as was originally designed with O_MAYEXEC. Because then > enforcement is gated by the kernel -- the process does not get a file > descriptor _at all_, no matter what LD_PRELOAD or seccomp tricks it into > doing. Being able to check a path name or a file descriptor (with the same syscall) is more flexible and cover more use cases. The execveat(2) interface, including current and future flags, is dedicated to file execution. I then think that using execveat(2) for this kind of check makes more sense, and will easily evolve with this syscall. > > And this thinking also applies to faccessat() too: if a process can be > tricked into thinking the access check passed, it'll happily interpret > whatever. :( But not being able to open the fd _at all_ when O_MAYEXEC > is being checked seems substantially safer to me... If attackers can filter execveat(2), they can also filter open(2) and any other syscalls. In all cases, that would mean an issue in the security policy.