From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933565AbcH2Pc0 (ORCPT ); Mon, 29 Aug 2016 11:32:26 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:52815 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757421AbcH2PcV (ORCPT ); Mon, 29 Aug 2016 11:32:21 -0400 Subject: Re: [PATCH v1] mm, sysctl: Add sysctl for controlling VM_MAYEXEC taint To: Will Drewry , "Kirill A. Shutemov" References: <1472229004-9658-1-git-send-email-robert.foss@collabora.com> <20160826213227.GA11393@node.shutemov.name> Cc: Andrew Morton , kirill.shutemov@linux.intel.com, vbabka@suse.cz, mhocko@suse.com, mingo@kernel.org, dave.hansen@linux.intel.com, hannes@cmpxchg.org, dan.j.williams@intel.com, iamjoonsoo.kim@lge.com, acme@redhat.com, Kees Cook , mgorman@techsingularity.net, atomlin@redhat.com, Hugh Dickins , dyoung@redhat.com, Al Viro , Daniel Cashman , w@1wt.eu, idryomov@gmail.com, yang.shi@linaro.org, vkuznets@redhat.com, vdavydov@virtuozzo.com, vitalywool@gmail.com, oleg@redhat.com, gang.chen.5i5j@gmail.com, koct9i@gmail.com, aarcange@redhat.com, aryabinin@virtuozzo.com, kuleshovmail@gmail.com, minchan@kernel.org, mguzik@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ivan Krasin , Roland McGrath , Mandeep Singh Baines , Ben Zhang , Filipe Brandenburger From: Robert Foss Message-ID: <160c3fc3-6d75-18d3-8575-98bb41e0543a@collabora.com> Date: Mon, 29 Aug 2016 11:31:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-08-29 11:25 AM, Will Drewry wrote: > > > On Fri, Aug 26, 2016 at 4:32 PM, Kirill A. Shutemov > > wrote: > > On Fri, Aug 26, 2016 at 12:30:04PM -0400, robert.foss@collabora.com > wrote: > > From: Will Drewry > > > > > This patch proposes a sysctl knob that allows a privileged user to > > disable ~VM_MAYEXEC tainting when mapping in a vma from a MNT_NOEXEC > > mountpoint. It does not alter the normal behavior resulting from > > attempting to directly mmap(PROT_EXEC) a vma (-EPERM) nor the behavior > > of any other subsystems checking MNT_NOEXEC. > > Wouldn't it be equal to remounting all filesystems without noexec from > attacker POV? It's hardly a fence to make additional mprotect(PROT_EXEC) > call, before starting executing code from such filesystems. > > If administrator of the system wants this, he can just mount filesystem > without noexec, no new kernel code required. And it's more fine-grained > than this. > > So, no, I don't think we should add knob like this. Unless I miss > something. > > > I don't believe this patch is necessary anymore (though, thank you > Robert for testing and re-sending!). > > The primary offenders wrt to needing to mmap/mprotect a file in /dev/shm > was the older nvidia > driver (binary only iirc) and the Chrome Native Client code. > > The reason why half-exec is an "ok" (half) mitigation is because it > blocks simple gadgets and other paths for using loadable libraries or > binaries (via glibc) as it disallows mmap(PROT_EXEC) even though it > allows mprotect(PROT_EXEC). This stops ld in its tracks since it does > the obvious thing and uses mmap(PROT_EXEC). > > I think time has marched on and this patch is now something I can toss > in the dustbin of history. Both Chrome's Native Client and an older > nvidia driver relied on creating-then-unlinking a file in tmpfs, but > there is now a better facility! > > > NAK. > > > Agreed - this is old and software that predicated it should be gone.. I > hope. :) Splendid, patch dropped! Thanks Will and Kirill! Rob. > > > > > It is motivated by a common /dev/shm, /tmp usecase. There are few > > facilities for creating a shared memory segment that can be remapped in > > the same process address space with different permissions. > > What about using memfd_create(2) for such cases? You'll get a file > descriptor from in-kernel tmpfs (shm_mnt) which is not exposed to > userspace for remount as noexec. > > > This is a relatively old patch ( https://lwn.net/Articles/455256/ > ) which predated memfd_create(). > memfd_create() is the right solution to this problem! > > > Thanks again! > will