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 second.openwall.net (second.openwall.net [193.110.157.125]) by smtp.lore.kernel.org (Postfix) with SMTP id 32B10C2BD09 for ; Tue, 9 Jul 2024 20:42:52 +0000 (UTC) Received: (qmail 29723 invoked by uid 550); 9 Jul 2024 20:42:39 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 29703 invoked from network); 9 Jul 2024 20:42:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1720557751; bh=zJhS7of/CAzAVW6Q59+RaHwwypnLdu6BBXvJ+or8B1M=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qBhszl/JKbeRElfW9FNgl6e0YtKN0eXAABvDYpCkPxvHKO6FYUnOCU+NSyU5Vk/Bq SKoFzFVP5RewPlBZEWP6/sCwGbLP4G82aZve9Pz856jfAr3qWb074ap4csT0oj6F8o 0B/tm4NzPlpNRodzi04GFH2QnJGO/DLLZ89Tjhng= Date: Tue, 9 Jul 2024 22:42:26 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Florian Weimer 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 , 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 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 1/5] exec: Add a new AT_CHECK flag to execveat(2) Message-ID: <20240709.aa5ahChoo7No@digikod.net> References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <87bk3bvhr1.fsf@oldenburg.str.redhat.com> <87ed83etpk.fsf@oldenburg.str.redhat.com> <87r0c3dc1c.fsf@oldenburg.str.redhat.com> <20240709.gae4cu4Aiv6s@digikod.net> <87ed82283l.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87ed82283l.fsf@oldenburg.str.redhat.com> X-Infomaniak-Routing: alpha On Tue, Jul 09, 2024 at 12:05:50PM +0200, Florian Weimer wrote: > * Mickaël Salaün: > > >> > If we want to avoid that, we could have an agreed-upon error code which > >> > the LSM can signal that it'll never fail AT_CHECK checks, so we only > >> > have to perform the extra system call once. > > > > I'm not sure to follow. Either we check executable code or we don't, > > but it doesn't make sense to only check some parts (except for migration > > of user space code in a system, which is one purpose of the securebits > > added with the next patch). > > > > The idea with AT_CHECK is to unconditionnaly check executable right the > > same way it is checked when a file is executed. User space can decide > > to check that or not according to its policy (i.e. securebits). > > I meant it purely as a performance optimization, to skip future system > calls if we know they won't provide any useful information for this > process. In the grand scheme of things, the extra system call probably > does not matter because we already have to do costly things like mmap. Indeed, the performance impact of execveat+AT_CHECK should be negligible compared to everything else needed to interpret a script or spawn a process. Moreover, these checks should only be performed when SECBIT_SHOULD_EXEC_CHECK is set for the caller.