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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 E84F3C83003 for ; Wed, 29 Apr 2020 08:50:41 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 4F7D420775 for ; Wed, 29 Apr 2020 08:50:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F7D420775 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=digikod.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-18679-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 19681 invoked by uid 550); 29 Apr 2020 08:50:34 -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 19657 invoked from network); 29 Apr 2020 08:50:33 -0000 Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC To: Jann Horn , Florian Weimer Cc: kernel list , Aleksa Sarai , Alexei Starovoitov , Al Viro , Andy Lutomirski , Christian Heimes , 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: Date: Wed, 29 Apr 2020 10:50:19 +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 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. Indeed it makes sense to use RESOLVE_MAYEXEC for the dynamic linker too. Only the noexec mount option is taken into account for mmap(2) with PROT_EXEC, and if you can trick the dynamic linker with JOP as Jann explained, it may enable to execute new code. However, a kernel which forbids remapping memory with PROT_EXEC still enables to implement a W^X policy. Any JOP/ROP still enables unexpected code execution though. > > 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... As it is written in the documentation patch, this RESOLVE_MAYEXEC feature is an important missing piece, but to implement a consistent security policy we need to enable other restrictions starting with a noexec mount point policy. The purpose of this patch series is not to bring a full-feature LSM with process states handling, but it brings what is needed for LSMs such as SELinux, IMA or IPE to extend their capabilities to reach what you would expect.