linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jann Horn <jannh@google.com>,
	Linux API <linux-api@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	David Drysdale <drysdale@google.com>
Subject: Re: new ...at() flag: AT_NO_JUMPS
Date: Fri, 05 May 2017 15:28:47 -0500	[thread overview]
Message-ID: <8737cj6oao.fsf@xmission.com> (raw)
In-Reply-To: <20170505043902.GP29622@ZenIV.linux.org.uk> (Al Viro's message of "Fri, 5 May 2017 05:39:02 +0100")

Al Viro <viro@ZenIV.linux.org.uk> writes:

> On Thu, May 04, 2017 at 08:46:49PM -0700, Linus Torvalds wrote:
>> On Thu, May 4, 2017 at 7:47 PM, Jann Horn <jannh@google.com> wrote:
>> >
>> > Thread 1 starts an AT_BENEATH path walk using an O_PATH fd
>> > pointing to /srv/www/example.org/foo; the path given to the syscall is
>> > "bar/../../../../etc/passwd". The path walk enters the "bar" directory.
>> > Thread 2 moves /srv/www/example.org/foo/bar to
>> > /srv/www/example.org/bar.
>> > Thread 1 processes the rest of the path ("../../../../etc/passwd"), never
>> > hitting /srv/www/example.org/foo in the process.
>> >
>> > I'm not really familiar with the VFS internals, but from a coarse look
>> > at the patch, it seems like it wouldn't block this?
>> 
>> I think you're right.
>> 
>> I guess it would be safe for the RCU case due to the sequence number
>> check, but not the non-RCU case.
>
> 	Yes and no...  FWIW, to exclude that it would suffice to have
> mount --rbind /src/www/example.org/foo /srv/www/example.org/foo done first.
> Then this kind of race will end up with -ENOENT due to path_connected()
> logics in follow_dotdot_rcu()/follow_dotdot().  I'm not sure about the
> intended applications, though - is that thing supposed to be used along with
> some horror like seccomp, or...?

As I recall the general idea is that if you have an application like a
tftp server or a web server that gets a path from a possibly dubious
source.  Instead of implementing an error prone validation logic in
userspace you can use AT_BENEATH and be certain the path resolution
stays in bounds.

As you can do stronger things as root this seems mostly targeted at
non-root applications.

I seem to recall part of the idea was to sometimes pair this to seccomp
to be certain your application can't escape a sandbox.  That plays to
seccomp limitations that it can inspect flags as they reside in
registers but seccomp can't follow pointers.

Which all suggests that we would want something similar to is_subdir
when AT_BENEATH is specified that we check every time we follow ..
that would verify that on the same filesystem we stay below and
that we also stay on a mount that is below.  mount --move has
all of the same challenges for enforcing you stay within bounds
as rename does.

Eric

  parent reply	other threads:[~2017-05-05 20:35 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 22:04 Al Viro
2017-04-29 23:17 ` Andy Lutomirski
2017-04-29 23:25   ` Al Viro
2017-04-30  1:13     ` Andy Lutomirski
2017-04-30  4:38     ` Matthew Wilcox
2017-04-30 16:10       ` Al Viro
2017-05-01  4:52         ` Andy Lutomirski
2017-05-01  5:15           ` Al Viro
2017-05-01 17:36 ` Jann Horn
2017-05-01 19:37   ` Andy Lutomirski
2017-05-05  0:30   ` Al Viro
2017-05-05  0:44     ` Andy Lutomirski
2017-05-05  1:06       ` Al Viro
2017-05-05  1:27     ` Linus Torvalds
2017-05-05  3:00       ` Al Viro
2017-05-05  4:01         ` Linus Torvalds
2017-05-05  4:31           ` Andy Lutomirski
2017-05-05  2:47     ` Jann Horn
2017-05-05  3:46       ` Linus Torvalds
2017-05-05  4:39         ` Al Viro
2017-05-05  4:44           ` Andy Lutomirski
2017-05-05 20:04             ` Eric W. Biederman
2017-05-05 20:28           ` Eric W. Biederman [this message]
2017-05-08 19:34             ` Mickaël Salaün
2017-05-18  8:50     ` David Drysdale
2017-09-10 20:26 Jürg Billeter

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=8737cj6oao.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=drysdale@google.com \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    --subject='Re: new ...at() flag: AT_NO_JUMPS' \
    /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

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).