Message-ID: <87lf56bllc.fsf@disp2133>
Date:   Thu, 12 Aug 2021 12:48:31 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     "Andy Lutomirski" <luto@...nel.org>
Cc:     "David Hildenbrand" <david@...hat.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Al Viro" <viro@...iv.linux.org.uk>,
        "Alexey Dobriyan" <adobriyan@...il.com>,
        "Steven Rostedt" <rostedt@...dmis.org>,
        "Peter Zijlstra \(Intel\)" <peterz@...radead.org>,
        "Arnaldo Carvalho de Melo" <acme@...nel.org>,
        "Mark Rutland" <mark.rutland@....com>,
        "Alexander Shishkin" <alexander.shishkin@...ux.intel.com>,
        "Jiri Olsa" <jolsa@...hat.com>,
        "Namhyung Kim" <namhyung@...nel.org>,
        "Petr Mladek" <pmladek@...e.com>,
        "Sergey Senozhatsky" <sergey.senozhatsky@...il.com>,
        "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
        "Rasmus Villemoes" <linux@...musvillemoes.dk>,
        "Kees Cook" <keescook@...omium.org>,
        "Greg Ungerer" <gerg@...ux-m68k.org>,
        "Geert Uytterhoeven" <geert@...ux-m68k.org>,
        "Mike Rapoport" <rppt@...nel.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Vincenzo Frascino" <vincenzo.frascino@....com>,
        "Chinwen Chang" <chinwen.chang@...iatek.com>,
        "Michel Lespinasse" <walken@...gle.com>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Matthew Wilcox \(Oracle\)" <willy@...radead.org>,
        "Huang Ying" <ying.huang@...el.com>,
        "Jann Horn" <jannh@...gle.com>, "Feng Tang" <feng.tang@...el.com>,
        "Kevin Brodsky" <Kevin.Brodsky@....com>,
        "Michael Ellerman" <mpe@...erman.id.au>,
        "Shawn Anastasio" <shawn@...stas.io>,
        "Steven Price" <steven.price@....com>,
        "Nicholas Piggin" <npiggin@...il.com>,
        "Christian Brauner" <christian.brauner@...ntu.com>,
        "Jens Axboe" <axboe@...nel.dk>,
        "Gabriel Krisman Bertazi" <krisman@...labora.com>,
        "Peter Xu" <peterx@...hat.com>,
        "Suren Baghdasaryan" <surenb@...gle.com>,
        "Shakeel Butt" <shakeelb@...gle.com>,
        "Marco Elver" <elver@...gle.com>,
        "Daniel Jordan" <daniel.m.jordan@...cle.com>,
        "Nicolas Viennot" <Nicolas.Viennot@...sigma.com>,
        "Thomas Cedeno" <thomascedeno@...gle.com>,
        "Collin Fijalkovich" <cfijalkovich@...gle.com>,
        "Michal Hocko" <mhocko@...e.com>,
        "Miklos Szeredi" <miklos@...redi.hu>,
        "Chengguang Xu" <cgxu519@...ernel.net>,
        Christian König 
        <ckoenig.leichtzumerken@...il.com>, linux-unionfs@...r.kernel.org,
        "Linux API" <linux-api@...r.kernel.org>,
        "the arch\/x86 maintainers" <x86@...nel.org>,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v1 0/7] Remove in-tree usage of MAP_DENYWRITE

"Andy Lutomirski" <luto@...nel.org> writes:

> On Thu, Aug 12, 2021, at 10:32 AM, Eric W. Biederman wrote:
>> David Hildenbrand <david@...hat.com> writes:
>> 
>> > This series is based on v5.14-rc5 and corresponds code-wise to the
>> > previously sent RFC [1] (the RFC still applied cleanly).
>> >
>> > This series removes all in-tree usage of MAP_DENYWRITE from the kernel
>> > and removes VM_DENYWRITE. We stopped supporting MAP_DENYWRITE for
>> > user space applications a while ago because of the chance for DoS.
>> > The last renaming user is binfmt binary loading during exec and
>> > legacy library loading via uselib().
>> >
>> > With this change, MAP_DENYWRITE is effectively ignored throughout the
>> > kernel. Although the net change is small, I think the cleanup in mmap()
>> > is quite nice.
>> >
>> > 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).
>> > 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.
>> 
>> So I think what we really want to do is to install executables with
>> and shared libraries without write permissions and immutable.  So that
>> upgrades/replacements of the libraries and executables are forced to
>> rename or unlink them.  We need the immutable bit as CAP_DAC_OVERRIDE
>> aka being root ignores the writable bits when a file is opened for
>> write.  However CAP_DAC_OVERRIDE does not override the immutable state
>> of a file.
>
> If we really want to do this, I think we'd want a different flag
> that's more like sealed.  Non-root users should be able to do this,
> too.
>
> Or we could just more gracefully handle users that overwrite running
> programs.

I had a blind spot, and Florian Weimer made a very reasonable request.
Apparently userspace for shared libraires uses MAP_PRIVATE.

So we almost don't care if the library is overwritten.  We loose some
efficiency and apparently there are some corner cases like the library
being extended past the end of the exiting file that are problematic.

Given that MAP_PRIVATE for shared libraries is our strategy for handling
writes to shared libraries perhaps we just need to use MAP_POPULATE or a
new related flag (perhaps MAP_PRIVATE_NOW) that just makes certain that
everything mapped from the executable is guaranteed to be visible from
the time of the mmap, and any changes from the filesystem side after
that are guaranteed to cause a copy on write.

Once we get that figured out we could consider getting rid of deny-write
entirely.

Eric

Powered by blists - more mailing lists