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.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 07100C43214 for ; Thu, 12 Aug 2021 12:21:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9C97F6101E for ; Thu, 12 Aug 2021 12:21:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9C97F6101E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 0CB058D0006; Thu, 12 Aug 2021 08:21:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07B448D0002; Thu, 12 Aug 2021 08:21:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E84328D0006; Thu, 12 Aug 2021 08:21:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id CADEF8D0002 for ; Thu, 12 Aug 2021 08:21:07 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6DB6A2311C for ; Thu, 12 Aug 2021 12:21:07 +0000 (UTC) X-FDA: 78466338174.23.88E04F3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf01.hostedemail.com (Postfix) with ESMTP id 1925E5042A2C for ; Thu, 12 Aug 2021 12:21:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1628770866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=67VxuLoInCrL14SlTIDdgh0fWkak+9n8Xf3485B2J+A=; b=SU8pLbYU1tDBqkcqLnnUZK8aQiWsq5rqMgswzcvL6f4LSsai5tlXgQGIJq1eVV9VEBvB5c EEmwLqmNfJIDXmGbsc+D/6YodJx+8S7fBsvi+qUxzN9CeQ/5qI93txQPQ3XJ9HfQPk3TtZ Lb1YNiQL6nHqBN7IxP8MiHkeo8IWocU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-8-8nhzabGoPE6Cer6nrOhDfQ-1; Thu, 12 Aug 2021 08:21:04 -0400 X-MC-Unique: 8nhzabGoPE6Cer6nrOhDfQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 078E81008062; Thu, 12 Aug 2021 12:20:59 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1D6A5D9C6; Thu, 12 Aug 2021 12:20:38 +0000 (UTC) From: Florian Weimer To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Alexander Viro , Alexey Dobriyan , Steven Rostedt , Peter Zijlstra , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Petr Mladek , Sergey Senozhatsky , Andy Shevchenko , Rasmus Villemoes , Kees Cook , "Eric W. Biederman" , Greg Ungerer , Geert Uytterhoeven , Mike Rapoport , Vlastimil Babka , Vincenzo Frascino , Chinwen Chang , Michel Lespinasse , Catalin Marinas , "Matthew Wilcox (Oracle)" , Huang Ying , Jann Horn , Feng Tang , Kevin Brodsky , Michael Ellerman , Shawn Anastasio , Steven Price , Nicholas Piggin , Christian Brauner , Jens Axboe , Gabriel Krisman Bertazi , Peter Xu , Suren Baghdasaryan , Shakeel Butt , Marco Elver , Daniel Jordan , Nicolas Viennot , Thomas Cedeno , Collin Fijalkovich , Michal Hocko , Miklos Szeredi , Chengguang Xu , Christian =?utf-8?Q?K=C3=B6nig?= , linux-unionfs@vger.kernel.org, linux-api@vger.kernel.org, x86@kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE References: <20210812084348.6521-1-david@redhat.com> Date: Thu, 12 Aug 2021 14:20:37 +0200 In-Reply-To: <20210812084348.6521-1-david@redhat.com> (David Hildenbrand's message of "Thu, 12 Aug 2021 10:43:41 +0200") Message-ID: <87r1eyg8h6.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 1925E5042A2C X-Stat-Signature: zqpqcix8tq3owughgmnnrzby4nssj3fk Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=SU8pLbYU; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf01.hostedemail.com: domain of fweimer@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=fweimer@redhat.com X-HE-Tag: 1628770866-404475 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: * David Hildenbrand: > There are some (minor) user-visible changes with this series: > 1. We no longer deny write access to shared libaries loaded via legacy > uselib(); this behavior matches modern user space e.g., via dlopen(). > 2. We no longer deny write access to the elf interpreter after exec > completed, treating it just like shared libraries (which it often is). We have a persistent issue with people using cp (or similar tools) to replace system libraries. Since the file is truncated first, all relocations and global data are replaced by file contents, result in difficult-to-diagnose crashes. It would be nice if we had a way to prevent this mistake. It doesn't have to be MAP_DENYWRITE or MAP_COPY. It could be something completely new, like an option that turns every future access beyond the truncation point into a signal (rather than getting bad data or bad code and crashing much later). I don't know how many invalid copy operations are currently thwarted by the current program interpreter restriction. I doubt that lifting the restriction matters. > 3. We always deny write access to the file linked via /proc/pid/exe: > sys_prctl(PR_SET_MM_EXE_FILE) will fail if write access to the file > cannot be denied, and write access to the file will remain denied > until the link is effectivel gone (exec, termination, > PR_SET_MM_EXE_FILE) -- just as if exec'ing the file. > > I was wondering if we really care about permanently disabling write access > to the executable, or if it would be good enough to just disable write > access while loading the new executable during exec; but I don't know > the history of that -- and it somewhat makes sense to deny write access > at least to the main executable. With modern user space -- dlopen() -- we > can effectively modify the content of shared libraries while being used. Is there a difference between ET_DYN and ET_EXEC executables? Thanks, Florian