netdev - 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]

Date:   Mon, 3 Oct 2022 19:49:39 +0100
From:   Al Viro <viro@...iv.linux.org.uk>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     David Laight <David.Laight@...lab.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 12:07:27PM -0500, Eric W. Biederman wrote:

> > fchdir() will get you out if you have an open fd to a directory
> > outside the chroot.
> > The 'usual' way out requires a process outside the chroot to
> > just use mvdir().
> > But there isn't supposed to be a way to get out.
> 
> As I recall the history chroot was a quick hack to allow building a
> building against a different version of the binaries than were currently
> installed.  It was not built as a security feature.

A last-moment prerelease hack in v7, by the look of it; at that point it
hadn't even tried to modify ".." behaviour in the directory you'd been
chrooted into - just modified the starting point for resolving absolute pathnames.

Not even token attempts of confinement until 1982 commit by Bill Joy,
during one of the namei rewrites.  No idea how when non-BSD branches
had picked that.

At no point did chroot(2) switch the current directory.  fchdir(2) doesn't
add anything to the situation when
	chdir("/");
	chroot("some_directory");
	chdir("../../../../../../../..");
	chroot(".");
will break you out of it nicely.

Again, chroot(2) had never been intended to be root-resistant; there's
a reason why "drop elevated priveleges right after chrooting" is
in all kinds of UNIX FAQs (very likely in Stevens et.al. as well -
I don't have the relevant volume in front of me, but it's certainly
something covered in textbooks).

chroot(2) can be useful in confining processes, but you need to be
really careful about the ways you use it.