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 4D378C2BD09 for ; Sat, 6 Jul 2024 15:33:07 +0000 (UTC) Received: (qmail 10082 invoked by uid 550); 6 Jul 2024 15:32:55 -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 10048 invoked from network); 6 Jul 2024 15:32:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720279966; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oBRFKUriB/1HZETMXeJgCSmmjgsoAHSm5ov/S8Qilac=; b=WXOaq3Y0yvfR8nUSbAmcUJJ1KUS+ktc0BTfTEpw8h+GR5oozA0H1XvyOBC2xgN5wHSOkh4 35sJgqVIQuiLX6LhL8vlH6tLXihpTwX1+NO5fIvMgvhXGzOfestgDDnMSoREn9JZHE8rJv 27LjgATT7pfzxpU54ye8GG/Mcw8ozCE= X-MC-Unique: QvlzTIlEODCCaBeRXTNIIQ-1 From: Florian Weimer To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: 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 , 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 1/5] exec: Add a new AT_CHECK flag to execveat(2) In-Reply-To: <20240706.poo9ahd3La9b@digikod.net> (=?utf-8?Q?=22Micka=C3=AB?= =?utf-8?Q?l_Sala=C3=BCn=22's?= message of "Sat, 6 Jul 2024 16:55:51 +0200") References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <87bk3bvhr1.fsf@oldenburg.str.redhat.com> <20240706.poo9ahd3La9b@digikod.net> Date: Sat, 06 Jul 2024 17:32:12 +0200 Message-ID: <871q46bkoz.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 * Micka=C3=ABl Sala=C3=BCn: > On Fri, Jul 05, 2024 at 08:03:14PM +0200, Florian Weimer wrote: >> * Micka=C3=ABl Sala=C3=BCn: >>=20 >> > Add a new AT_CHECK flag to execveat(2) to check if a file would be >> > allowed for execution. The main use case is for script interpreters a= nd >> > dynamic linkers to check execution permission according to the kernel's >> > security policy. Another use case is to add context to access logs e.g= ., >> > which script (instead of interpreter) accessed a file. As any >> > executable code, scripts could also use this check [1]. >>=20 >> Some distributions no longer set executable bits on most shared objects, >> which I assume would interfere with AT_CHECK probing for shared objects. > > A file without the execute permission is not considered as executable by > the kernel. The AT_CHECK flag doesn't change this semantic. Please > note that this is just a check, not a restriction. See the next patch > for the optional policy enforcement. > > Anyway, we need to define the policy, and for Linux this is done with > the file permission bits. So for systems willing to have a consistent > execution policy, we need to rely on the same bits. Yes, that makes complete sense. I just wanted to point out the odd interaction with the old binutils bug and the (sadly still current) kernel bug. >> Removing the executable bit is attractive because of a combination of >> two bugs: a binutils wart which until recently always set the entry >> point address in the ELF header to zero, and the kernel not checking for >> a zero entry point (maybe in combination with an absent program >> interpreter) and failing the execve with ELIBEXEC, instead of doing the >> execve and then faulting at virtual address zero. Removing the >> executable bit is currently the only way to avoid these confusing >> crashes, so I understand the temptation. > > Interesting. Can you please point to the bug report and the fix? I > don't see any ELIBEXEC in the kernel. The kernel hasn't been fixed yet. I do think this should be fixed, so that distributions can bring back the executable bit. Thanks, Florian