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 4CFB6C433E1 for ; Tue, 11 Aug 2020 08:49:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 30DAF206B2 for ; Tue, 11 Aug 2020 08:49:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728345AbgHKIta (ORCPT ); Tue, 11 Aug 2020 04:49:30 -0400 Received: from smtp-8faa.mail.infomaniak.ch ([83.166.143.170]:34021 "EHLO smtp-8faa.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728403AbgHKIt2 (ORCPT ); Tue, 11 Aug 2020 04:49:28 -0400 Received: from smtp-2-0000.mail.infomaniak.ch (unknown [10.5.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4BQmjL1hcRzlhjP4; Tue, 11 Aug 2020 10:49:26 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4BQmjJ5QnQzlh8Tj; Tue, 11 Aug 2020 10:49:24 +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> <917bb071-8b1a-3ba4-dc16-f8d7b4cc849f@digikod.net> <20200810230521.GG1236603@ZenIV.linux.org.uk> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Tue, 11 Aug 2020 10:49:24 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20200810230521.GG1236603@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-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 11/08/2020 01:05, Al Viro wrote: > On Tue, Aug 11, 2020 at 12:43:52AM +0200, Mickaël Salaün wrote: > >> Hooking on open is a simple design that enables processes to check files >> they intend to open, before they open them. > > Which is a good thing, because...? > >> 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.). > > That's what "unspecified" means - as far as the kernel concerned, it's > "something completely opaque, will let these hooks to play, semantics is > entirely up to them". I see it as an access controls mechanism; access may be granted or denied, as for O_RDONLY, O_WRONLY or (non-Linux) O_EXEC. Even for common access controls, there are capabilities to bypass them (i.e. CAP_DAC_OVERRIDE), but multiple layers may enforce different complementary policies. > >> 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). > > ????? You explicitly assume a cooperating caller. As said in the below (removed) reply, no, quite the contrary. > If it can't be trusted > to issue the check between open and use, or can be manipulated (ptraced, > etc.) into not doing so, how can you rely upon the flag having been passed > in the first place? And TOCTOU window is definitely not wider that way. OK, I guess it would be considered a bug in the application (e.g. buggy resource management between threads). > > If you want to have it done immediately after open(), bloody well do it > immediately after open. If attacker has subverted your control flow to the > extent that allows them to hit descriptor table in the interval between > these two syscalls, you have already lost - they'll simply prevent that > flag from being passed. > > What's the point of burying it inside openat2()? A convenient multiplexor > to hook into? We already have one - it's called do_syscall_... > To check as soon as possible without opening something that should not be opened in the first place. Isn't a dedicated syscall a bit too much for this feature? What about adding a new command/flag to fcntl(2)?