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.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,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 0B3F5C47247 for ; Tue, 5 May 2020 14:58:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E891B206B9 for ; Tue, 5 May 2020 14:58:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729416AbgEEO6M (ORCPT ); Tue, 5 May 2020 10:58:12 -0400 Received: from smtp-bc0a.mail.infomaniak.ch ([45.157.188.10]:34005 "EHLO smtp-bc0a.mail.infomaniak.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729123AbgEEO6M (ORCPT ); Tue, 5 May 2020 10:58:12 -0400 Received: from smtp-2-0001.mail.infomaniak.ch (unknown [10.5.36.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 49GjWS0PVPzlhDCG; Tue, 5 May 2020 16:57:40 +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 49GjWP0npnzlvfC7; Tue, 5 May 2020 16:57:37 +0200 (CEST) Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC To: Christian Heimes , Jann Horn , Florian Weimer Cc: kernel list , Aleksa Sarai , Alexei Starovoitov , Al Viro , Andy Lutomirski , Daniel Borkmann , Deven Bowers , Eric Chiang , James Morris , Jan Kara , Jonathan Corbet , Kees Cook , 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 , Linux API , linux-security-module , linux-fsdevel References: <20200428175129.634352-1-mic@digikod.net> <87blnb48a3.fsf@mid.deneb.enyo.de> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: <8d47dfe6-1ff7-e5fe-d4d0-c2493db3fd63@digikod.net> Date: Tue, 5 May 2020 16:57:36 +0200 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On 01/05/2020 13:47, Christian Heimes wrote: > On 29/04/2020 00.01, Jann Horn wrote: >> On Tue, Apr 28, 2020 at 11:21 PM Florian Weimer wrote: >>> * Jann Horn: >>> >>>> Just as a comment: You'd probably also have to use RESOLVE_MAYEXEC in >>>> the dynamic linker. >>> >>> Absolutely. In typical configurations, the kernel does not enforce >>> that executable mappings must be backed by files which are executable. >>> It's most obvious with using an explicit loader invocation to run >>> executables on noexec mounts. RESOLVE_MAYEXEC is much more useful >>> than trying to reimplement the kernel permission checks (or what some >>> believe they should be) in userspace. >> >> Oh, good point. >> >> That actually seems like something Mickaël could add to his series? If >> someone turns on that knob for "When an interpreter wants to execute >> something, enforce that we have execute access to it", they probably >> also don't want it to be possible to just map files as executable? So >> perhaps when that flag is on, the kernel should either refuse to map >> anything as executable if it wasn't opened with RESOLVE_MAYEXEC or >> (less strict) if RESOLVE_MAYEXEC wasn't used, print a warning, then >> check whether the file is executable and bail out if not? >> >> A configuration where interpreters verify that scripts are executable, >> but other things can just mmap executable pages, seems kinda >> inconsistent... > > +1 > > I worked with Steve Downer on Python PEP 578 [1] that added audit hooks > and PyFile_OpenCode() to CPython. A PyFile_OpenCode() implementation > with RESOLVE_MAYEXEC will hep to secure loading of Python code. But > Python also includes a wrapper of libffi. ctypes or cffi can load native > code from either shared libraries with dlopen() or execute native code > from mmap() regions. For example SnakeEater [2] is a clever attack that > abused memfd_create syscall and proc filesystem to execute code. > > A consistent security policy must also ensure that mmap() PROT_EXEC > enforces the same restrictions as RESOLVE_MAYEXEC. The restriction > doesn't have be part of this patch, though. > > Christian > > [1] https://www.python.org/dev/peps/pep-0578/ > [2] https://github.com/nullbites/SnakeEater/blob/master/SnakeEater2.py To be consistent, a "noexec" policy must indeed also restricts features such as mprotect(2) and mmap(2) which may enable to set arbitrary memory as executable. This can be restricted with SELinux (i.e. execmem, execmod,execheap and execstack permissions), PaX MPROTECT [1] or SARA [2]. [1] https://pax.grsecurity.net/docs/mprotect.txt [2] https://lore.kernel.org/lkml/1562410493-8661-1-git-send-email-s.mesoraca16@gmail.com/