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=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 BB4A7C433E2 for ; Thu, 14 May 2020 19:21:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A38AB20643 for ; Thu, 14 May 2020 19:21:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727987AbgENTV3 (ORCPT ); Thu, 14 May 2020 15:21:29 -0400 Received: from smtp-bc0f.mail.infomaniak.ch ([45.157.188.15]:52189 "EHLO smtp-bc0f.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727835AbgENTV2 (ORCPT ); Thu, 14 May 2020 15:21:28 -0400 Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 49NLxc0FXZzlhNp2; Thu, 14 May 2020 21:21:24 +0200 (CEST) Received: from ns3096276.ip-94-23-54.eu (unknown [94.23.54.103]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 49NLxZ3CmQzljTrx; Thu, 14 May 2020 21:21:22 +0200 (CEST) Subject: Re: [PATCH v5 3/6] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC To: Kees Cook , Stephen Smalley Cc: linux-kernel , Aleksa Sarai , Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , Daniel Borkmann , Deven Bowers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Lakshmi Ramasubramanian , Matthew Garrett , Matthew Wilcox , Michael Kerrisk , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= , Mimi Zohar , =?UTF-8?Q?Philippe_Tr=c3=a9buchet?= , 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-integrity@vger.kernel.org, LSM List , Linux FS Devel References: <20200505153156.925111-1-mic@digikod.net> <20200505153156.925111-4-mic@digikod.net> <202005131525.D08BFB3@keescook> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <0e654c90-bec5-6ba1-771e-648da94ef547@digikod.net> Date: Thu, 14 May 2020 21:21:21 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: <202005131525.D08BFB3@keescook> 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/05/2020 01:27, Kees Cook wrote: > On Wed, May 13, 2020 at 11:37:16AM -0400, Stephen Smalley wrote: >> On Tue, May 5, 2020 at 11:33 AM Mickaël Salaün wrote: >>> >>> Enable to forbid access to files open with O_MAYEXEC. Thanks to the >>> noexec option from the underlying VFS mount, or to the file execute >>> permission, userspace can enforce these execution policies. This may >>> allow script interpreters to check execution permission before reading >>> commands from a file, or dynamic linkers to allow shared object loading. >>> >>> Add a new sysctl fs.open_mayexec_enforce to enable system administrators >>> to enforce two complementary security policies according to the >>> installed system: enforce the noexec mount option, and enforce >>> executable file permission. Indeed, because of compatibility with >>> installed systems, only system administrators are able to check that >>> this new enforcement is in line with the system mount points and file >>> permissions. A following patch adds documentation. >>> >>> For tailored Linux distributions, it is possible to enforce such >>> restriction at build time thanks to the CONFIG_OMAYEXEC_STATIC option. >>> The policy can then be configured with CONFIG_OMAYEXEC_ENFORCE_MOUNT and >>> CONFIG_OMAYEXEC_ENFORCE_FILE. >>> >>> Being able to restrict execution also enables to protect the kernel by >>> restricting arbitrary syscalls that an attacker could perform with a >>> crafted binary or certain script languages. 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). To get a >>> consistent execution policy, additional memory restrictions should also >>> be enforced (e.g. thanks to SELinux). >>> >>> Signed-off-by: Mickaël Salaün >>> Reviewed-by: Thibaut Sautereau >>> Cc: Aleksa Sarai >>> Cc: Al Viro >>> Cc: Kees Cook >>> --- >> >>> diff --git a/fs/namei.c b/fs/namei.c >>> index 33b6d372e74a..70f179f6bc6c 100644 >>> --- a/fs/namei.c >>> +++ b/fs/namei.c >>> @@ -411,10 +412,90 @@ static int sb_permission(struct super_block *sb, struct inode *inode, int mask) >> >>> +#if defined(CONFIG_SYSCTL) && !defined(CONFIG_OMAYEXEC_STATIC) >>> +int proc_omayexec(struct ctl_table *table, int write, void __user *buffer, >>> + size_t *lenp, loff_t *ppos) >>> +{ >>> + int error; >>> + >>> + if (write) { >>> + struct ctl_table table_copy; >>> + int tmp_mayexec_enforce; >>> + >>> + if (!capable(CAP_MAC_ADMIN)) >>> + return -EPERM; >> >> Not fond of using CAP_MAC_ADMIN here (or elsewhere outside of security >> modules). The ability to set this sysctl is not equivalent to being >> able to load a MAC policy, set arbitrary MAC labels on >> processes/files, etc. > > That's fair. In that case, perhaps this could just use the existing > _sysadmin helper? (Though I should note that these perm checks actually > need to be in the open, not the read/write ... I thought there was a > series to fix that, but I can't find it now. Regardless, that's > orthogonal to this series.) OK, I'll switch to CAP_SYS_ADMIN with proc_dointvec_minmax_sysadmin().