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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 73B3BC4724C for ; Fri, 1 May 2020 04:03:12 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id C98AA2073E for ; Fri, 1 May 2020 04:03:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C98AA2073E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=namei.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-18692-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 21853 invoked by uid 550); 1 May 2020 04:03:05 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 21833 invoked from network); 1 May 2020 04:03:04 -0000 Date: Fri, 1 May 2020 14:02:16 +1000 (AEST) From: James Morris To: =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= cc: linux-kernel@vger.kernel.org, Aleksa Sarai , Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , Daniel Borkmann , Deven Bowers , Eric Chiang , Florian Weimer , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?ISO-8859-15?Q?Micka=EBl_Sala=FCn?= , Mimi Zohar , =?ISO-8859-15?Q?Philippe_Tr=E9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount property In-Reply-To: <20200428175129.634352-3-mic@digikod.net> Message-ID: References: <20200428175129.634352-1-mic@digikod.net> <20200428175129.634352-3-mic@digikod.net> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1665246916-2066436414-1588305635=:29679" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1665246916-2066436414-1588305635=:29679 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: 8BIT Content-ID: On Tue, 28 Apr 2020, Mickaël Salaün wrote: > An LSM doesn't get path information related to an access request to open > an inode. This new (internal) MAY_EXECMOUNT flag enables an LSM to > check if the underlying mount point of an inode is marked as executable. > This is useful to implement a security policy taking advantage of the > noexec mount option. > > This flag is set according to path_noexec(), which checks if a mount > point is mounted with MNT_NOEXEC or if the underlying superblock is > SB_I_NOEXEC. > > Signed-off-by: Mickaël Salaün > Reviewed-by: Philippe Trébuchet > Reviewed-by: Thibaut Sautereau > Cc: Aleksa Sarai > Cc: Al Viro > Cc: Kees Cook Are there any existing LSMs which plan to use this aspect? -- James Morris --1665246916-2066436414-1588305635=:29679--