All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Fields <bfields@fieldses.org>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Jann Horn <jannh@google.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	jlayton@kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	shuah@kernel.org, David Howells <dhowells@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	christian@brauner.io, Tycho Andersen <tycho@tycho.ws>,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-kselftest@vger.kernel.org, dev@opencontainers.org,
	containers@lists.linux-foundation.org,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution
Date: Mon, 1 Oct 2018 09:55:58 -0400	[thread overview]
Message-ID: <20181001135558.GB25003@fieldses.org> (raw)
In-Reply-To: <20181001054246.gfinmx3api7kjhmc@ryuk>

On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn <jannh@google.com> wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> > 
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> > 
> > If the root of your walk is below an attacker-controlled directory,
> > this of course means that you lose instantly. If you point the root of
> > the walk at a directory out of which a process in the container
> > wouldn't be able to move the file, you're probably kinda mostly fine -
> > as long as you know, for certain, that nothing else on the system
> > would ever do that. But I still wouldn't feel good about that.
> 
> Please correct me if I'm wrong here (this is the first patch I've
> written for VFS). Isn't the retry/LOOKUP_REVAL code meant to handle this

No.

...
> Speaking naively, doesn't it make sense to invalidate the walk if a path
> component was modified? Or is this something that would be far too
> costly with little benefit?

Lookups and renames can definitely proceed in parallel, and yes I
suspect it would be difficult to get good performance and guaranteed
forward progress if you required lookup of the full path to be atomic
with respect to renames.

--b.

WARNING: multiple messages have this Message-ID (diff)
From: bfields at fieldses.org (Bruce Fields)
Subject: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution
Date: Mon, 1 Oct 2018 09:55:58 -0400	[thread overview]
Message-ID: <20181001135558.GB25003@fieldses.org> (raw)
In-Reply-To: <20181001054246.gfinmx3api7kjhmc@ryuk>

On Mon, Oct 01, 2018 at 03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn <jannh at google.com> wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> > 
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> > 
> > If the root of your walk is below an attacker-controlled directory,
> > this of course means that you lose instantly. If you point the root of
> > the walk at a directory out of which a process in the container
> > wouldn't be able to move the file, you're probably kinda mostly fine -
> > as long as you know, for certain, that nothing else on the system
> > would ever do that. But I still wouldn't feel good about that.
> 
> Please correct me if I'm wrong here (this is the first patch I've
> written for VFS). Isn't the retry/LOOKUP_REVAL code meant to handle this

No.

...
> Speaking naively, doesn't it make sense to invalidate the walk if a path
> component was modified? Or is this something that would be far too
> costly with little benefit?

Lookups and renames can definitely proceed in parallel, and yes I
suspect it would be difficult to get good performance and guaranteed
forward progress if you required lookup of the full path to be atomic
with respect to renames.

--b.

WARNING: multiple messages have this Message-ID (diff)
From: bfields@fieldses.org (Bruce Fields)
Subject: [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution
Date: Mon, 1 Oct 2018 09:55:58 -0400	[thread overview]
Message-ID: <20181001135558.GB25003@fieldses.org> (raw)
Message-ID: <20181001135558.xGx5iBcxa_-sz_YpOJg7lZB35ZiAMqtbFgS1ozz1jxU@z> (raw)
In-Reply-To: <20181001054246.gfinmx3api7kjhmc@ryuk>

On Mon, Oct 01, 2018@03:44:28PM +1000, Aleksa Sarai wrote:
> On 2018-09-29, Jann Horn <jannh@google.com> wrote:
> > The problem is what happens if a folder you are walking through is
> > concurrently moved out of the chroot. Consider the following scenario:
> > 
> > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > Something else concurrently moves /A/B/C to /A/C. This can result in
> > the following:
> > 
> > 1. You start the path walk and reach /A/B/C.
> > 2. The other process moves /A/B/C to /A/C. Your path walk is now at /A/C.
> > 3. Your path walk follows the first ".." up into /A. This is outside
> > the process root, but you never actually encountered the process root,
> > so you don't notice.
> > 4. Your path walk follows the second ".." up to /. Again, this is
> > outside the process root, but you don't notice.
> > 5. Your path walk walks down to /etc/passwd, and the open completes
> > successfully. You now have an fd pointing outside your chroot.
> > 
> > If the root of your walk is below an attacker-controlled directory,
> > this of course means that you lose instantly. If you point the root of
> > the walk at a directory out of which a process in the container
> > wouldn't be able to move the file, you're probably kinda mostly fine -
> > as long as you know, for certain, that nothing else on the system
> > would ever do that. But I still wouldn't feel good about that.
> 
> Please correct me if I'm wrong here (this is the first patch I've
> written for VFS). Isn't the retry/LOOKUP_REVAL code meant to handle this

No.

...
> Speaking naively, doesn't it make sense to invalidate the walk if a path
> component was modified? Or is this something that would be far too
> costly with little benefit?

Lookups and renames can definitely proceed in parallel, and yes I
suspect it would be difficult to get good performance and guaranteed
forward progress if you required lookup of the full path to be atomic
with respect to renames.

--b.

  parent reply	other threads:[~2018-10-01 13:56 UTC|newest]

Thread overview: 165+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-29 10:34 [PATCH 0/3] namei: implement various scoping AT_* flags Aleksa Sarai
2018-09-29 10:34 ` Aleksa Sarai
2018-09-29 10:34 ` cyphar
2018-09-29 10:34 ` [PATCH 1/3] namei: implement O_BENEATH-style " Aleksa Sarai
2018-09-29 10:34   ` Aleksa Sarai
2018-09-29 10:34   ` cyphar
2018-09-29 14:48   ` Christian Brauner
2018-09-29 14:48     ` Christian Brauner
2018-09-29 14:48     ` christian
2018-09-29 15:34     ` Aleksa Sarai
2018-09-29 15:34       ` Aleksa Sarai
2018-09-29 15:34       ` cyphar
2018-09-30  4:38   ` Aleksa Sarai
2018-09-30  4:38     ` Aleksa Sarai
2018-09-30  4:38     ` cyphar
2018-10-01 12:28   ` Jann Horn
2018-10-01 12:28     ` Jann Horn
2018-10-01 12:28     ` jannh
2018-10-01 13:00     ` Christian Brauner
2018-10-01 13:00       ` Christian Brauner
2018-10-01 13:00       ` christian
2018-10-01 16:04       ` Aleksa Sarai
2018-10-01 16:04         ` Aleksa Sarai
2018-10-01 16:04         ` cyphar
2018-10-04 17:20         ` Christian Brauner
2018-10-04 17:20           ` Christian Brauner
2018-10-04 17:20           ` christian
2018-09-29 13:15 ` [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution Aleksa Sarai
2018-09-29 13:15   ` Aleksa Sarai
2018-09-29 13:15   ` cyphar
2018-09-29 13:15   ` [PATCH 3/3] selftests: vfs: add AT_* path resolution tests Aleksa Sarai
2018-09-29 13:15     ` Aleksa Sarai
2018-09-29 13:15     ` cyphar
2018-09-29 16:35   ` [PATCH 2/3] namei: implement AT_THIS_ROOT chroot-like path resolution Jann Horn
2018-09-29 16:35     ` Jann Horn
2018-09-29 16:35     ` jannh
2018-09-29 17:25     ` Andy Lutomirski
2018-09-29 17:25       ` Andy Lutomirski
2018-09-29 17:25       ` luto
2018-10-01  9:46       ` Aleksa Sarai
2018-10-01  9:46         ` Aleksa Sarai
2018-10-01  9:46         ` cyphar
2018-10-01  5:44     ` Aleksa Sarai
2018-10-01  5:44       ` Aleksa Sarai
2018-10-01  5:44       ` cyphar
2018-10-01 10:13       ` Jann Horn
2018-10-01 10:13         ` Jann Horn
2018-10-01 10:13         ` jannh
2018-10-01 16:18         ` Aleksa Sarai
2018-10-01 16:18           ` Aleksa Sarai
2018-10-01 16:18           ` cyphar
2018-10-04 17:27           ` Christian Brauner
2018-10-04 17:27             ` Christian Brauner
2018-10-04 17:27             ` christian
2018-10-01 10:42       ` Christian Brauner
2018-10-01 10:42         ` Christian Brauner
2018-10-01 10:42         ` christian
2018-10-01 11:29         ` Jann Horn
2018-10-01 11:29           ` Jann Horn
2018-10-01 11:29           ` jannh
2018-10-01 12:35           ` Christian Brauner
2018-10-01 12:35             ` Christian Brauner
2018-10-01 12:35             ` christian
2018-10-01 13:55       ` Bruce Fields [this message]
2018-10-01 13:55         ` Bruce Fields
2018-10-01 13:55         ` bfields
2018-10-01 14:28       ` Andy Lutomirski
2018-10-01 14:28         ` Andy Lutomirski
2018-10-01 14:28         ` luto
2018-10-02  7:32         ` Aleksa Sarai
2018-10-02  7:32           ` Aleksa Sarai
2018-10-02  7:32           ` cyphar
2018-10-03 22:09           ` Andy Lutomirski
2018-10-03 22:09             ` Andy Lutomirski
2018-10-03 22:09             ` luto
2018-10-03 22:09             ` Andy Lutomirski
2018-10-06 20:56           ` Florian Weimer
2018-10-06 20:56             ` Florian Weimer
2018-10-06 20:56             ` fw
2018-10-06 21:49             ` Christian Brauner
2018-10-06 21:49               ` Christian Brauner
2018-10-06 21:49               ` christian
2018-10-01 14:00     ` Christian Brauner
2018-10-01 14:00       ` Christian Brauner
2018-10-01 14:00       ` christian
2018-10-04 16:26     ` Aleksa Sarai
2018-10-04 16:26       ` Aleksa Sarai
2018-10-04 16:26       ` cyphar
2018-10-04 17:31       ` Christian Brauner
2018-10-04 17:31         ` Christian Brauner
2018-10-04 17:31         ` christian
2018-10-04 18:26       ` Jann Horn
2018-10-04 18:26         ` Jann Horn
2018-10-04 18:26         ` jannh
2018-10-05 15:07         ` Aleksa Sarai
2018-10-05 15:07           ` Aleksa Sarai
2018-10-05 15:07           ` cyphar
2018-10-05 15:55           ` Jann Horn
2018-10-05 15:55             ` Jann Horn
2018-10-05 15:55             ` jannh
2018-10-06  2:10             ` Aleksa Sarai
2018-10-06  2:10               ` Aleksa Sarai
2018-10-06  2:10               ` cyphar
2018-10-08 10:50               ` Jann Horn
2018-10-08 10:50                 ` Jann Horn
2018-10-08 10:50                 ` jannh
2018-09-29 14:25 ` [PATCH 0/3] namei: implement various scoping AT_* flags Andy Lutomirski
2018-09-29 14:25   ` Andy Lutomirski
2018-09-29 14:25   ` luto
2018-09-29 15:45   ` Aleksa Sarai
2018-09-29 15:45     ` Aleksa Sarai
2018-09-29 15:45     ` cyphar
2018-09-29 16:34     ` Andy Lutomirski
2018-09-29 16:34       ` Andy Lutomirski
2018-09-29 16:34       ` luto
2018-09-29 19:44       ` Matthew Wilcox
2018-09-29 19:44         ` Matthew Wilcox
2018-09-29 19:44         ` willy
2018-09-29 14:38 ` Christian Brauner
2018-09-29 14:38   ` Christian Brauner
2018-09-29 14:38   ` christian
2018-09-30  4:44   ` Aleksa Sarai
2018-09-30  4:44     ` Aleksa Sarai
2018-09-30  4:44     ` cyphar
2018-09-30 13:54 ` Alban Crequy
2018-09-30 13:54   ` Alban Crequy
2018-09-30 13:54   ` alban
2018-09-30 14:02   ` Christian Brauner
2018-09-30 14:02     ` Christian Brauner
2018-09-30 14:02     ` christian
2018-09-30 19:45 ` Mickaël Salaün
2018-09-30 19:45   ` Mickaël Salaün
2018-09-30 19:45   ` Mickaël Salaün
2018-09-30 19:45   ` 
2018-09-30 21:46   ` Jann Horn
2018-09-30 21:46     ` Jann Horn
2018-09-30 21:46     ` Jann Horn
2018-09-30 21:46     ` jannh
2018-09-30 22:37     ` Mickaël Salaün
2018-09-30 22:37       ` Mickaël Salaün
2018-09-30 22:37       ` 
2018-10-01 20:14       ` James Morris
2018-10-01 20:14         ` James Morris
2018-10-01 20:14         ` jmorris
2018-10-01  4:08 ` Dave Chinner
2018-10-01  4:08   ` Dave Chinner
2018-10-01  4:08   ` david
2018-10-01  5:47   ` Aleksa Sarai
2018-10-01  5:47     ` Aleksa Sarai
2018-10-01  5:47     ` cyphar
2018-10-01  6:14     ` Dave Chinner
2018-10-01  6:14       ` Dave Chinner
2018-10-01  6:14       ` david
2018-10-01 13:28 ` David Laight
2018-10-01 13:28   ` David Laight
2018-10-01 13:28   ` David.Laight
2018-10-01 13:28   ` David Laight
2018-10-01 16:15   ` Aleksa Sarai
2018-10-01 16:15     ` Aleksa Sarai
2018-10-01 16:15     ` cyphar
2018-10-01 16:15     ` Aleksa Sarai
2018-10-03 13:21     ` David Laight
2018-10-03 13:21       ` David Laight
2018-10-03 13:21       ` David.Laight
2018-10-03 13:21       ` David Laight

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=20181001135558.GB25003@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=dev@opencontainers.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=jannh@google.com \
    --cc=jlayton@kernel.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=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=shuah@kernel.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 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.