From: Adam Borowski <kilobyte@angband.pl>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
David Howells <dhowells@redhat.com>,
Eric Biederman <ebiederm@xmission.com>,
Jann Horn <jannh@google.com>,
Christian Brauner <christian@brauner.io>,
David Drysdale <drysdale@google.com>,
Tycho Andersen <tycho@tycho.ws>,
Linux Containers <containers@lists.linux-foundation.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexei Starovoitov <ast@kernel.org>,
Chanho Min <chanho.min@lge.com>, Oleg Nesterov <oleg@redhat.com>,
Aleksa Sarai <asarai@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution
Date: Thu, 25 Apr 2019 15:22:49 +0200 [thread overview]
Message-ID: <20190425132249.GA26669@angband.pl> (raw)
In-Reply-To: <20190424153806.64qkkmkudzodxnz2@yavin>
On Thu, Apr 25, 2019 at 01:38:06AM +1000, Aleksa Sarai wrote:
> * openat(2) ignores unknown flags, meaning that old kernels will ignore
> new programs trying to use O_THISROOT and might end up causing
> security issues. Yes, it'd be trivial to check whether the new O_*
> flags are supported at start-up, but I think a security feature
> shouldn't have a foot-gun associated with it. In fact, I didn't know
> openat(2) ignored unknown flags until I wrote this patchset -- I
> doubt many other userspace developers do either.
For this reason, I propose every new syscall that has flags to follow a
bitmask scheme, where any flag assigned a bit in the upper half returns
EOPNOTSUPP when called on an old kernel. That would allow defining which
flags can be safely ignored and which can't.
It otherwise takes major hacks to implement a fail-if-not-supported flag
while keeping compat with old kernels. For example, for mmap(), MAP_SHARED
has been duplicated as MAP_SHARED_VALIDATE just to allow an unrelated flag
(MAP_SYNC) to fail on old kernels.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven giant trumpets are playing in the
⠈⠳⣄⠀⠀⠀⠀ sky. Your cat demands food. The priority should be obvious...
next prev parent reply other threads:[~2019-04-25 13:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 14:37 [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Aleksa Sarai
2019-03-20 14:37 ` [PATCH RESEND v5 1/5] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-03-20 14:37 ` [PATCH RESEND v5 2/5] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-03-20 14:37 ` [PATCH RESEND v5 3/5] namei: O_THISROOT: chroot-like path resolution Aleksa Sarai
2019-03-20 14:37 ` [PATCH RESEND v5 4/5] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-03-20 14:37 ` [PATCH RESEND v5 5/5] binfmt_*: scope path resolution of interpreters Aleksa Sarai
2019-03-21 17:06 ` [PATCH RESEND v5 0/5] namei: vfs flags to restrict path resolution Andy Lutomirski
2019-03-25 13:04 ` Aleksa Sarai
2019-04-23 20:13 ` Kees Cook
2019-04-23 20:24 ` Christian Brauner
2019-04-24 15:38 ` Aleksa Sarai
2019-04-25 13:22 ` Adam Borowski [this message]
2019-04-25 19:45 ` Aleksa Sarai
-- strict thread matches above, loose matches on Subject: below --
2019-03-06 19:12 Aleksa Sarai
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=20190425132249.GA26669@angband.pl \
--to=kilobyte@angband.pl \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=asarai@suse.de \
--cc=ast@kernel.org \
--cc=bfields@fieldses.org \
--cc=chanho.min@lge.com \
--cc=christian@brauner.io \
--cc=containers@lists.linux-foundation.org \
--cc=cyphar@cyphar.com \
--cc=dhowells@redhat.com \
--cc=drysdale@google.com \
--cc=ebiederm@xmission.com \
--cc=jannh@google.com \
--cc=jlayton@kernel.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=oleg@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=tycho@tycho.ws \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).