From: Jann Horn <jannh@google.com>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: "Mickaël Salaün" <mic@digikod.net>,
"kernel list" <linux-kernel@vger.kernel.org>,
"Aleksa Sarai" <cyphar@cyphar.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Al Viro" <viro@zeniv.linux.org.uk>,
"Andy Lutomirski" <luto@kernel.org>,
"Christian Heimes" <christian@python.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Deven Bowers" <deven.desai@linux.microsoft.com>,
"Eric Chiang" <ericchiang@google.com>,
"James Morris" <jmorris@namei.org>, "Jan Kara" <jack@suse.cz>,
"Jonathan Corbet" <corbet@lwn.net>,
"Kees Cook" <keescook@chromium.org>,
"Matthew Garrett" <mjg59@google.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Michael Kerrisk" <mtk.manpages@gmail.com>,
"Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Philippe Trébuchet" <philippe.trebuchet@ssi.gouv.fr>,
"Scott Shell" <scottsh@microsoft.com>,
"Sean Christopherson" <sean.j.christopherson@intel.com>,
"Shuah Khan" <shuah@kernel.org>,
"Steve Dower" <steve.dower@python.org>,
"Steve Grubb" <sgrubb@redhat.com>,
"Thibaut Sautereau" <thibaut.sautereau@ssi.gouv.fr>,
"Vincent Strubel" <vincent.strubel@ssi.gouv.fr>,
"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
"Linux API" <linux-api@vger.kernel.org>,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC
Date: Wed, 29 Apr 2020 00:01:38 +0200 [thread overview]
Message-ID: <CAG48ez2TphTj-VdDaSjvnr0Q8BhNmT3n86xYz4bF3wRJmAMsMw@mail.gmail.com> (raw)
In-Reply-To: <87blnb48a3.fsf@mid.deneb.enyo.de>
On Tue, Apr 28, 2020 at 11:21 PM Florian Weimer <fw@deneb.enyo.de> 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...
next prev parent reply other threads:[~2020-04-28 22:02 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 17:51 [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC Mickaël Salaün
2020-04-28 17:51 ` [PATCH v3 1/5] fs: Add support for a RESOLVE_MAYEXEC flag on openat2(2) Mickaël Salaün
2020-05-01 4:04 ` James Morris
2020-05-01 14:14 ` Mickaël Salaün
2020-04-28 17:51 ` [PATCH v3 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount property Mickaël Salaün
2020-05-01 4:02 ` James Morris
2020-05-01 14:17 ` Mickaël Salaün
2020-04-28 17:51 ` [PATCH v3 3/5] fs: Enable to enforce noexec mounts or file exec through RESOLVE_MAYEXEC Mickaël Salaün
2020-05-01 4:22 ` James Morris
2020-05-01 14:32 ` Mickaël Salaün
2020-05-01 18:05 ` James Morris
2020-04-28 17:51 ` [PATCH v3 4/5] selftest/openat2: Add tests for RESOLVE_MAYEXEC enforcing Mickaël Salaün
2020-04-28 17:51 ` [PATCH v3 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl Mickaël Salaün
2020-04-28 19:21 ` [PATCH v3 0/5] Add support for RESOLVE_MAYEXEC Jann Horn
2020-04-28 21:20 ` Florian Weimer
2020-04-28 22:01 ` Jann Horn [this message]
2020-04-29 8:50 ` Mickaël Salaün
2020-05-01 11:47 ` Christian Heimes
2020-05-05 14:57 ` Mickaël Salaün
2020-04-30 1:54 ` Aleksa Sarai
2020-04-30 8:07 ` Christian Brauner
2020-04-30 10:45 ` Mickaël Salaün
2020-04-30 11:01 ` Lev R. Oshvang .
2020-05-01 3:53 ` James Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAG48ez2TphTj-VdDaSjvnr0Q8BhNmT3n86xYz4bF3wRJmAMsMw@mail.gmail.com \
--to=jannh@google.com \
--cc=ast@kernel.org \
--cc=christian@python.org \
--cc=corbet@lwn.net \
--cc=cyphar@cyphar.com \
--cc=daniel@iogearbox.net \
--cc=deven.desai@linux.microsoft.com \
--cc=ericchiang@google.com \
--cc=fw@deneb.enyo.de \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mic@digikod.net \
--cc=mickael.salaun@ssi.gouv.fr \
--cc=mjg59@google.com \
--cc=mtk.manpages@gmail.com \
--cc=philippe.trebuchet@ssi.gouv.fr \
--cc=scottsh@microsoft.com \
--cc=sean.j.christopherson@intel.com \
--cc=sgrubb@redhat.com \
--cc=shuah@kernel.org \
--cc=steve.dower@python.org \
--cc=thibaut.sautereau@ssi.gouv.fr \
--cc=vincent.strubel@ssi.gouv.fr \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.