Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp265690ybz; Thu, 30 Apr 2020 21:25:10 -0700 (PDT) X-Google-Smtp-Source: APiQypJGsAP1qdWpoB3xLOa27vC1iFjiNCbSbH3ZRdXjhkZ/Z9HSVAx1qYTAHPi74ULjjKuyxkxW X-Received: by 2002:aa7:d342:: with SMTP id m2mr1954360edr.130.1588307110543; Thu, 30 Apr 2020 21:25:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588307110; cv=none; d=google.com; s=arc-20160816; b=Bg1rsm414TdJus3eStDveQm2fhluYupDnCy++8RlvqCMrJvggTVR5OKJ1ou8rYnuoW pK37bxgTuCtMRnzFvphr2Wpnx9jDvzU/+7p+f72qrENttou0sOHRjHvS1TEqTjA/Rgy2 o7gzPeyY6bdNqjg2rIhalreIAPVvnJhgQeG75VggSC4jDU+no3OKe+y8591d/zrd5/np xj/j+TMjcByJCIURXPlJ8FTV4fICeJfxuq1WZFYvrbLoKVMQl/u0TfyI8cXBqHMJGe20 pka+0/KH4JZG5hYw5W5wT4FiOK+9lKppWDVfqXF3C6BNqZQIfevqfx1fi1a+MrN1Qx6j slVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-id:mime-version:user-agent :references:message-id:in-reply-to:subject:cc:to:from:date; bh=9h+jAReSrMhCe//3OSeN1w9GIKYnx+oTWkxs4Q6+j00=; b=LG8qMJFVcdP2iVlzzvBllv3Nvde+6NaK2T3ey3LKcQltK3+zju+lBzGX81SKQWPztT P57DALsjuzAw8yZl4eGDLDCd68f9UZOIdge8lzuklQEFbzF7sI0A1gs7IxtRlnNvvcGh URuai36wtfjatoLmeO6SaKtX5JO2jKAROfm/sZCfjtoS5AfL63AtILphCEL3GXpqceKi ZHT6TsBx20pdWxzT0JQyZGeGeNSIA5PQm5BezP/NPYDQWBiFPgEx5Hf/ZKOMEfNdxNnL SLoC9eOuGcBxhch1zH0fM2EBkq3d8JVFQa4oksTJd13KvbpWDsD9wMbYvPLfewzHL7Wa F7yA== 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 j9si1034244edn.415.2020.04.30.21.24.46; Thu, 30 Apr 2020 21:25:10 -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 S1728212AbgEAEXZ (ORCPT + 99 others); Fri, 1 May 2020 00:23:25 -0400 Received: from namei.org ([65.99.196.166]:56544 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726153AbgEAEXZ (ORCPT ); Fri, 1 May 2020 00:23:25 -0400 Received: from localhost (localhost [127.0.0.1]) by namei.org (8.14.4/8.14.4) with ESMTP id 0414MTSS031613; Fri, 1 May 2020 04:22:29 GMT Date: Fri, 1 May 2020 14:22:29 +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 3/5] fs: Enable to enforce noexec mounts or file exec through RESOLVE_MAYEXEC In-Reply-To: <20200428175129.634352-4-mic@digikod.net> Message-ID: References: <20200428175129.634352-1-mic@digikod.net> <20200428175129.634352-4-mic@digikod.net> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1665246916-573384471-1588306338=:29679" Content-ID: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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-573384471-1588306338=: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: > Enable to either propagate the mount options from the underlying VFS > mount to prevent execution, or to propagate the file execute permission. > This may allow a script interpreter to check execution permissions > before reading commands from a file. I'm finding the description of this patch difficult to understand. In the first case, this seems to mean: if you open a file with RESOLVE_MAYEXEC from a noexec mount, then it will fail. Correct? In the second case, do you mean a RESOLVE_MAYEXEC open will fail if the file does not have +x set for the user? > The main goal is to be able to protect the kernel by restricting > arbitrary syscalls that an attacker could perform with a crafted binary > or certain script languages. This sounds like the job of seccomp. Why is this part of MAYEXEC? > It also improves multilevel isolation > by reducing the ability of an attacker to use side channels with > specific code. These restrictions can natively be enforced for ELF > binaries (with the noexec mount option) but require this kernel > extension to properly handle scripts (e.g., Python, Perl). Again, not sure why you're talking about side channels and MAYEXEC and mount options. Are you more generally talking about being able to prevent execution of arbitrary script files included by an interpreter? > Add a new sysctl fs.open_mayexec_enforce to control this behavior. > Indeed, because of compatibility with installed systems, only the system > administrator is able to check that this new enforcement is in line with > the system mount points and file permissions. A following patch adds > documentation. I don't like the idea of any of this feature set being configurable. RESOLVE_MAYEXEC as a new flag should have well-defined, stable semantics. -- James Morris --1665246916-573384471-1588306338=:29679--