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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 55495C433E1 for ; Mon, 10 Aug 2020 22:44:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3D1C0206E9 for ; Mon, 10 Aug 2020 22:44:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726966AbgHJWn6 (ORCPT ); Mon, 10 Aug 2020 18:43:58 -0400 Received: from smtp-42a8.mail.infomaniak.ch ([84.16.66.168]:39391 "EHLO smtp-42a8.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726634AbgHJWn6 (ORCPT ); Mon, 10 Aug 2020 18:43:58 -0400 Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4BQWGg1kCrzlhK0h; Tue, 11 Aug 2020 00:43:55 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4BQWGc4GQPzlh8TN; Tue, 11 Aug 2020 00:43:52 +0200 (CEST) Subject: Re: [PATCH v7 0/7] Add support for O_MAYEXEC To: Al Viro Cc: Kees Cook , Andrew Morton , linux-kernel@vger.kernel.org, Aleksa Sarai , Alexei Starovoitov , Andy Lutomirski , Christian Brauner , Christian Heimes , Daniel Borkmann , Deven Bowers , Dmitry Vyukov , Eric Biggers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , Mimi Zohar , =?UTF-8?Q?Philippe_Tr=c3=a9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Tetsuo Handa , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org References: <20200723171227.446711-1-mic@digikod.net> <202007241205.751EBE7@keescook> <0733fbed-cc73-027b-13c7-c368c2d67fb3@digikod.net> <20200810202123.GC1236603@ZenIV.linux.org.uk> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <917bb071-8b1a-3ba4-dc16-f8d7b4cc849f@digikod.net> Date: Tue, 11 Aug 2020 00:43:52 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20200810202123.GC1236603@ZenIV.linux.org.uk> Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/08/2020 22:21, Al Viro wrote: > On Mon, Aug 10, 2020 at 10:11:53PM +0200, Mickaël Salaün wrote: >> It seems that there is no more complains nor questions. Do you want me >> to send another series to fix the order of the S-o-b in patch 7? > > There is a major question regarding the API design and the choice of > hooking that stuff on open(). And I have not heard anything resembling > a coherent answer. Hooking on open is a simple design that enables processes to check files they intend to open, before they open them. From an API point of view, this series extends openat2(2) with one simple flag: O_MAYEXEC. The enforcement is then subject to the system policy (e.g. mount points, file access rights, IMA, etc.). Checking on open enables to not open a file if it does not meet some requirements, the same way as if the path doesn't exist or (for whatever reasons, including execution permission) if access is denied. It is a good practice to check as soon as possible such properties, and it may enables to avoid (user space) time-of-check to time-of-use (TOCTOU) attacks (i.e. misuse of already open resources). It is important to keep in mind that the use cases we are addressing consider that the (user space) script interpreters (or linkers) are trusted and unaltered (i.e. integrity/authenticity checked). These are similar sought defensive properties as for SUID/SGID binaries: attackers can still launch them with malicious inputs (e.g. file paths, file descriptors, environment variables, etc.), but the binaries can then have a way to check if they can extend their trust to some file paths. Checking file descriptors may help in some use cases, but not the ones motivating this series. Checking (already) opened resources could be a *complementary* way to check execute permission, but it is not in the scope of this series.