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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6647C4707F for ; Tue, 5 Apr 2022 20:10:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358394AbiDEUED (ORCPT ); Tue, 5 Apr 2022 16:04:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1457337AbiDEQDG (ORCPT ); Tue, 5 Apr 2022 12:03:06 -0400 Received: from smtp-42ac.mail.infomaniak.ch (smtp-42ac.mail.infomaniak.ch [84.16.66.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 519C121818 for ; Tue, 5 Apr 2022 08:38:21 -0700 (PDT) Received: from smtp-2-0000.mail.infomaniak.ch (unknown [10.5.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4KXsHG6sFqzMpxx0; Tue, 5 Apr 2022 17:38:18 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [23.97.221.149]) by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4KXsHB10mbzlhNts; Tue, 5 Apr 2022 17:38:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digikod.net; s=20191114; t=1649173098; bh=CsXI63Mo7UO6r/uWwmX4gFbUZp/CXy5CRXKt0P6gt6c=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=gmHoadq5c/jpwjvzRlDxdSe/QMSdIkQfuWdwnlle2JMgrxICKuYw2Otz5agkacD7Z B3oSAGjmLbhr+bMhGpyxWhZRNmQP4WVnKkPPMB7gr9oFepQ8SCfZOo8micekUP/VgR nsB09g6YQOZdXoGywDPjQHeZ/pGkYe4CO0FU08J8= Message-ID: <1eeae491-7f4f-2cbc-7dbb-04e926c78b89@digikod.net> Date: Tue, 5 Apr 2022 17:38:39 +0200 MIME-Version: 1.0 User-Agent: Content-Language: en-US To: Linus Torvalds Cc: Kees Cook , Al Viro , Andrew Morton , Christian Heimes , Geert Uytterhoeven , James Morris , Luis Chamberlain , Mimi Zohar , Muhammad Usama Anjum , Paul Moore , =?UTF-8?Q?Philippe_Tr=c3=a9buchet?= , Shuah Khan , Steve Dower , Thibaut Sautereau , Vincent Strubel , linux-fsdevel , linux-integrity , Linux Kernel Mailing List , LSM List , Christian Brauner References: <20220321161557.495388-1-mic@digikod.net> <202204041130.F649632@keescook> <816667d8-2a6c-6334-94a4-6127699d4144@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Subject: Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/04/2022 23:28, Linus Torvalds wrote: > On Mon, Apr 4, 2022 at 1:29 PM Mickaël Salaün wrote: >> >> This initial proposal was using a new faccessat2(2) flag: >> AT_INTERPRETED, see >> https://lore.kernel.org/all/20200908075956.1069018-2-mic@digikod.net/ >> What do you think about that? I'm happy to get back to this version if >> everyone is OK with it. > > I'm certainly happi_er_ with that, but I find that particular patch > odd for other reasons. > > In no particular order: > > - what's with the insane non-C syntax? Double parentheses have no > actual meaning in C: > > if ((flags & AT_INTERPRETED)) { > if ((mode & MAY_EXEC)) { > > so I don't understand why you'd use that strance thing. I guess it comes from a previous version that ANDed two booleans. > > - why is this an AT_INTERPRETED flag? I don't understand the name, I > don't understand the semantics. I wasn't sure it was a good idea to add another mode bit, so I ended up using a flag to not break compatibility of other mode checks but extend the semantic to interpreted scripts. But I agree that a new mode makes sense. > > Why would that flag have the same value as AT_SYMLINK_FOLLOW? It was a bug. > > Why isn't this just a new _mode_ bit, which is what I feel is > sensible? We only use three bits (with no bits set meaning > "existence"), so we have *tons* of bits left in that namespace, and it > would make much more sense to me to have > > #define EXECVE_OK 8 > > which is the same as the "group exec" bit, so it actually makes > some kind of sense too. Looks fine to me. The "EXECVE_" prefix is a bit weird but it will not be defined in the kernel like X_OK and others anyway, and as you said, it matches S_IXGRP. > > - related to that "I don't understand the semantics", the > "documentation" for that thing doesn't make sense either: > > + The > + main usage is for script > + interpreters to enforce a policy > + consistent with the kernel's one > + (through sysctl configuration or LSM > + policy). */ I'll synchronize the documentation with a next series. > > Now, what I *think* you mean is See a following email in reply to Kees. [...] > > And yes, we still need to talk details: > > - no backwards compatibility issues, because we've happily always > checked 'mode' for being valid, so old kernels will always return > -EINVAL. > > - POSIX namespace issues for EXECVE_OK means that the name probably > needs some thinking (maybe we just need to call it __ACCESS_OK_EXECVE > internally or something - the kernel actually doesn't even export the > existing [FRWX]_OK values, because we "know" they map tho the usual > "owner RWX" bits, with F being "no bit set") Right, I cannot find a better name for now. See a following email in reply to Kees. [...] > > So to recap: I'm very much ok with some access() extension, but I > think even that very much needs clarification, and the existing patch > is just odd in many many ways. This v8 was kind of an early version, I'll update everything. Thanks!