From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-190c.mail.infomaniak.ch (smtp-190c.mail.infomaniak.ch [185.125.25.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 DE52EA93D for ; Sat, 6 Jul 2024 15:02:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.125.25.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720278129; cv=none; b=a4/bv6d5+qyPAs38aOVyRCllsCwBA/i5JTnVg9NMNnqhjFdra+PzMO+9K5s6Fli4Tou1nyL8HKgVji4fGqUutJsFb4y8iMUVrUAuJkb3OruE4zEXbgsUGzvLljB24Wh4I3zVV7lwRPTmihrSTGab4PcRJHCZX74dMf8cv6tM+1s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720278129; c=relaxed/simple; bh=xubLJoupr6a+LYfRAWqyUHezcWyAzUdQWTgVMGMPIGo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Kwc9PaA0uJip29ylliqN3s+EWdYu8J2mJ/llN6kcKiuhhRtssZWXRcIyf4Pw6HaN6pJe/o9sIEp+mTRNleE5QeRBLFpgHJ/qlv1cxbab4lDk7GGoLsoVKHhL1PEhk2SF0x1ZKzfGOpN4ufRvYAqW0Atqmf1+zhvWQ0/mIAvb9as= 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=QN2P3eSF; arc=none smtp.client-ip=185.125.25.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="QN2P3eSF" Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4WGYNj27fKzJ1r; Sat, 6 Jul 2024 16:56:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digikod.net; s=20191114; t=1720277765; bh=7uWel5mzu899dpbLYtvnqYOBClMoL9Rnhzi5iAwDfJs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QN2P3eSF26sxX6l10plfQdh/LRI9/mntYv1qM+y05JO01Svn8fGnnZErGxSw1jYJS u1K5IsaBLeNDRTrWQZgcHBJ58aMz+fl7eUe7XAy8wMlEo1Ja25QhZxFi/f8/SPLfII aZnbhuwhUvYGOuJ7PoYSH766Ssxj6PxeBeuNajRc= Received: from unknown by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4WGYNY53zczLym; Sat, 6 Jul 2024 16:55:57 +0200 (CEST) Date: Sat, 6 Jul 2024 16:55:51 +0200 From: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= To: Florian Weimer 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) Message-ID: <20240706.poo9ahd3La9b@digikod.net> References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <87bk3bvhr1.fsf@oldenburg.str.redhat.com> 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: <87bk3bvhr1.fsf@oldenburg.str.redhat.com> X-Infomaniak-Routing: alpha On Fri, Jul 05, 2024 at 08:03:14PM +0200, Florian Weimer wrote: > * Mickaël Salaün: > > > 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 and > > 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]. > > 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. > 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. FYI, AT_CHECK doesn't check the content of the file (unlike a full execve call). Anyway, I think we should not design a new kernel interface to work around a current user space bug.