Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 3 Oct 2022 15:03:03 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     David Laight <David.Laight@aculab.com>
Cc:     "'Eric W. Biederman'" <ebiederm@xmission.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [CFT][PATCH] proc: Update /proc/net to point at the accessing
 threads network namespace
Message-ID: <Yzrrl4MkM+xRysYd@ZenIV>
References: <YzXzXNAgcJeJ3M0d@ZenIV>
 <YzYK7k3tgZy3Pwht@ZenIV>
 <CAHk-=wihPFFE5KcsmOnOm1CALQDWqC1JTvrwSGBS08N5avVmEA@mail.gmail.com>
 <871qrt4ymg.fsf@email.froward.int.ebiederm.org>
 <87ill53igy.fsf_-_@email.froward.int.ebiederm.org>
 <ea14288676b045c29960651a649d66b9@AcuMS.aculab.com>
 <87a66g25wm.fsf@email.froward.int.ebiederm.org>
 <9bf5e96b383e4a979618cb0f729cb833@AcuMS.aculab.com>
 <YzjJNnzRTiSpwXHV@ZenIV>
 <592405fa149247f58d05a213b8c6f711@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <592405fa149247f58d05a213b8c6f711@AcuMS.aculab.com>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Mon, Oct 03, 2022 at 09:36:46AM +0000, David Laight wrote:
> ...
> > * ability to chroot(2) had always been equivalent to ability to undo
> > chroot(2).  If you want to prevent getting out of there, you need
> > (among other things) to prevent the processes to be confined from
> > further chroot(2).
> 
> Not always, certainly not historically.

Factually incorrect.

> chroot() inside a chroot() just constrained you further.

What it did was change your root directory.  Yes, deeper.
And leave your current directory where it had been.

Now, recall that chroot does *NOT* affect the
interpretation of .. other than in the current root.

Which means that attacker doing
	chdir("/");
	chroot(some_existing_directory);
	chdir("..");
will end up outside of the original chroot environment.

This is POSIX-mandated behaviour.  Moreover, that is behaviour of
historical Unices.  Any Unix programmer who tries to use chroot(2)
should be aware of that.  Ability of making chroot(2) calls
means the ability to break out of any chroot you are currently in.

> If fchdir() and openat() have broken that it is a serious
> problem.

Have you even read the mail you'd been replying to?  Where had anything
in the example given (OK sketched out) to you upthread involve fchdir()
or openat()?