From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-bc0c.mail.infomaniak.ch (smtp-bc0c.mail.infomaniak.ch [45.157.188.12]) (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 6427314E2D0 for ; Tue, 23 Jul 2024 13:16:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.157.188.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721740575; cv=none; b=ZRhWeCUHGHIWT/9AzTksPbEpxtDfYlYi2vAaRABW0MdRbLoMpBENui8tLMvJrRCfdotHomOAVD7iLN+TigoUuJP7f8mXjrpqTDUU4a3G7h+Mh+U2o2t5kfhTZFN+p4cWCiX/9dp0dGhV5euq+vdFUTDS7hvEuN9FThUo7aJzIdU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721740575; c=relaxed/simple; bh=QMbBvsDvncNdYCUjercLgXYGwm9cw4B8dwwqcwc43qs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=asjv6YpwU5A6ny8adgbexAxxRZBrIms2Z8vFyL42CH36T5za//u5Lxo6FyarKQfKSy37g/0E4yla6J+zcuYkkBVojlN+XqM1g0O4u8sC3/5kn//08U37H+XsGcKZ2sEDNcExIvdCELWz/PEUtDDES5yYyneP1u9q1P4rogL+qaA= 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=FCjlvbAS; arc=none smtp.client-ip=45.157.188.12 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="FCjlvbAS" Received: from smtp-3-0001.mail.infomaniak.ch (smtp-3-0001.mail.infomaniak.ch [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4WSyMZ5WFDzn6f; Tue, 23 Jul 2024 15:16:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1721740570; bh=Pf0FM4WG3BfxDSQVA4M55cgkTKksMUjPRdTroutu9Oo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FCjlvbASQWVZs6wFIJ7CYIUNPpU08+8kx5R20nitTBK4l5K87AnNQWkpcsKFDR6hE gpfmB2MQMrvo6MuyqTIdChlBaae0KIfoHcQhAYfJsRpmK6nhKm8he4/DzOFtKd2oCY ysaH1iREu4CkMpBMxGNNvN4WwTUJScRShOwLzris= Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4WSyMY60KPz8Q2; Tue, 23 Jul 2024 15:16:09 +0200 (CEST) Date: Tue, 23 Jul 2024 15:16:07 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Andy Lutomirski Cc: Steve Dower , 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, Elliott Hughes Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2) Message-ID: <20240723.Tae5oovie2ah@digikod.net> References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <20240717.AGh2shahc9ee@digikod.net> <20240718.Niexoo0ahch0@digikod.net> Precedence: bulk X-Mailing-List: linux-api@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: X-Infomaniak-Routing: alpha On Sat, Jul 20, 2024 at 09:59:33AM +0800, Andy Lutomirski wrote: > > On Jul 18, 2024, at 8:22 PM, Mickaël Salaün wrote: > > > > On Thu, Jul 18, 2024 at 09:02:56AM +0800, Andy Lutomirski wrote: > >>>> On Jul 17, 2024, at 6:01 PM, Mickaël Salaün wrote: > >>> > >>> 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. > >> > >> Circling back to my previous comment (did that ever get noticed?), I > > > > Yes, I replied to your comments. Did I miss something? > > I missed that email in the pile, sorry. I’ll reply separately. > > > > >> don’t think this is quite right: > >> > >> https://lore.kernel.org/all/CALCETrWYu=PYJSgyJ-vaa+3BGAry8Jo8xErZLiGR3U5h6+U0tA@mail.gmail.com/ > >> > >> On a basic system configuration, a given path either may or may not be > >> executed. And maybe that path has some integrity check (dm-verity, > >> etc). So the kernel should tell the interpreter/loader whether the > >> target may be executed. All fine. > >> > >> But I think the more complex cases are more interesting, and the > >> “execute a program” process IS NOT BINARY. An attempt to execute can > >> be rejected outright, or it can be allowed *with a change to creds or > >> security context*. It would be entirely reasonable to have a policy > >> that allows execution of non-integrity-checked files but in a very > >> locked down context only. > > > > I guess you mean to transition to a sandbox when executing an untrusted > > file. This is a good idea. I talked about role transition in the > > patch's description: > > > > With the information that a script interpreter is about to interpret a > > script, an LSM security policy can adjust caller's access rights or log > > execution request as for native script execution (e.g. role transition). > > This is possible thanks to the call to security_bprm_creds_for_exec(). > > … > > > This patch series brings the minimal building blocks to have a > > consistent execution environment. Role transitions for script execution > > are left to LSMs. For instance, we could extend Landlock to > > automatically sandbox untrusted scripts. > > I’m not really convinced. There’s more to building an API that > enables LSM hooks than merely sticking the hook somewhere in kernel > code. It needs to be a defined API. If you call an operation “check”, > then people will expect it to check, not to change the caller’s > credentials. And people will mess it up in both directions (e.g. > callers will call it and then open try to load some library that they > should have loaded first, or callers will call it and forget to close > fds first. > > And there should probably be some interaction with dumpable as well. > If I “check” a file for executability, that should not suddenly allow > someone to ptrace me? > > And callers need to know to exit on failure, not carry on. > > > More concretely, a runtime that fully opts in to this may well "check" > multiple things. For example, if I do: > > $ ld.so ~/.local/bin/some_program (i.e. I literally execve ld.so) > > then ld.so will load several things: > > ~/.local/bin/some_program > libc.so > other random DSOs, some of which may well be in my home directory > > And for all ld.so knows, some_program is actually an interpreter and > will "check" something else. And the LSMs have absolutely no clue > what's what. So I think for this to work right, the APIs need to be a > lot more expressive and explicit: > > check_library(fd to libc.so); <-- does not transition or otherwise drop privs > check_transition_main_program(fd to ~/.local/bin/some_program); <-- > may drop privs > > and if some_program is really an interpreter, then it will do: > > check_library(fd to some thing imported by the script); > check_transition_main_program(fd to the actual script); > > And maybe that takes a parameter that gets run eval-style: > > check_unsafe_user_script("actual contents of snippet"); > > The actual spelling of all this doesn't matter so much. But the user > code and the kernel code need to be on the same page as to what the > user program is doing and what it's asking the kernel program to do. I agree. I'll remove any references to "role transition". This kind of feature should come with something like getpeercon/setexeccon(3). > > --Andy >