linux-kernel - Re: [CFT][PATCH] proc: Update /proc/net to point at the accessing threads network namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yzrrl4MkM+xRysYd@ZenIV>
Date:   Mon, 3 Oct 2022 15:03:03 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     David Laight <David.Laight@...lab.com>
Cc:     "'Eric W. Biederman'" <ebiederm@...ssion.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [CFT][PATCH] proc: Update /proc/net to point at the accessing
 threads network namespace

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()?