Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp436280pxk; Fri, 11 Sep 2020 10:50:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx2L8xYKkj9zPyHDq5blHkvYAnKr9dqGuaINHzHsmt3Q1yCh3qF1mIi9Ee/7zvCrWEpu9qN X-Received: by 2002:a05:6402:1710:: with SMTP id y16mr3573469edu.197.1599846605336; Fri, 11 Sep 2020 10:50:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599846605; cv=none; d=google.com; s=arc-20160816; b=vSni0DaNSxHlPIcrp7nsrglFJ+3J9QlM0nponRcvY8GIAM8h6vDx6wWQx4/ITftOCy 01w+6CrrcZlA2rQn4MycFplzVfzwtkkpEGQOG0d0McU4kPwDatfHmucFHuPqsuzF/7Nh UJQThJfOkdfIIlYt/jHjgA4gU8yptGjiPuEACOG4bjg3k258di2MgPZIKQEGTwMqKXbC I0RWaEhhiVFVuY1Af0lQVZ71q0mprNiUbEu6TG0+op2htfvq3HJVrVVztU5zbcM10ypr J5o1FDmVS7tcqV+TiQlg+wqRYZSr/tIVa2nUDN4qAm0aJ/EkV4GO6d0DQGfOca6AZLWz G8RQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=weqiJEQDo/eM0CprQLmJfrKQMC9R8oF/DdfD5jTOY9Y=; b=RD9ml7i5ZRAh9N3aMObM0fnqLnNYCyfCbCXeMPRonkcYDMFPDqStWNLBmx6pzrNNLl 4JgiHdq/FDaaffqTrnG0M2pmZkh1Aq0QC1IAEToAZ0INSX5oHr2zk0SP4lEGSgln3l9m XRbiZxOcum3SnNJTSiT4LHbk8wN2FlhHFORfJH7sp4CJhODL/dMWDlkcH+wCPhyPAVWi oFAjoKcHktC/7r0H5q5jnteeCdAMqp2uL425vEnqKyjPuXnLmapcbo5M+ik5AgEZH1/Q RRV/MdQfDNaCrPPhg7wpfKrRQOhjbK4SWGRFw81/6nsVdaG/WeISbwMOWrBe03R0KCW+ 9DHg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x17si1885868edi.428.2020.09.11.10.49.41; Fri, 11 Sep 2020 10:50:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725817AbgIKRqp (ORCPT + 99 others); Fri, 11 Sep 2020 13:46:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725803AbgIKMQj (ORCPT ); Fri, 11 Sep 2020 08:16:39 -0400 Received: from smtp-8fad.mail.infomaniak.ch (smtp-8fad.mail.infomaniak.ch [IPv6:2001:1600:3:17::8fad]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5738BC061573 for ; Fri, 11 Sep 2020 05:16:36 -0700 (PDT) Received: from smtp-3-0000.mail.infomaniak.ch (unknown [10.4.36.107]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Bnvqv0ZqWzlhfqK; Fri, 11 Sep 2020 14:16:27 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4Bnvqq5mSFzlh8T4; Fri, 11 Sep 2020 14:16:23 +0200 (CEST) Subject: Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC) To: Matthew Wilcox , Al Viro Cc: Mimi Zohar , linux-kernel@vger.kernel.org, Aleksa Sarai , Alexei Starovoitov , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Christian Brauner , Christian Heimes , Daniel Borkmann , Deven Bowers , Dmitry Vyukov , Eric Biggers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Lakshmi Ramasubramanian , Matthew Garrett , Michael Kerrisk , Miklos Szeredi , =?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: <20200910164612.114215-1-mic@digikod.net> <20200910170424.GU6583@casper.infradead.org> <880bb4ee-89a2-b9b0-747b-0f779ceda995@digikod.net> <20200910184033.GX6583@casper.infradead.org> <20200910200010.GF1236603@ZenIV.linux.org.uk> <20200910200543.GY6583@casper.infradead.org> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <3dd9b2b3-6304-03df-bfba-13864169453e@digikod.net> Date: Fri, 11 Sep 2020 14:16:23 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <20200910200543.GY6583@casper.infradead.org> Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/09/2020 22:05, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: >> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: >>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Micka?l Sala?n wrote: >>>> There is also the use case of noexec mounts and file permissions. From >>>> user space point of view, it doesn't matter which kernel component is in >>>> charge of defining the policy. The syscall should then not be tied with >>>> a verification/integrity/signature/appraisal vocabulary, but simply an >>>> access control one. >>> >>> permission()? >> >> int lsm(int fd, const char *how, char *error, int size); >> >> Seriously, this is "ask LSM to apply special policy to file"; let's >> _not_ mess with flags, etc. for that; give it decent bandwidth >> and since it's completely opaque for the rest of the kernel, >> just a pass a string to be parsed by LSM as it sees fit. Well, I don't know why you're so angry against LSM, but as noticed by Matthew, the main focus of this patch series is not about LSM (no hook, no security/* code, only file permission and mount option checks, nothing fancy). Moreover, the syscall you're proposing doesn't make sense, but I guess it's yet another sarcastic reply. Please, cool down. We asked for constructive comments and already followed your previous requests (even if we didn't get answers for some questions), but seriously, this one is nonsense. > > Hang on, it does have some things which aren't BD^W^WLSM. It lets > the interpreter honour the mount -o noexec option. I presume it's > not easily defeated by > cat /home/salaun/bin/bad.pl | perl - > Funny. I know there is a lot of text and links but please read the commit messages before further comments.