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]

Date:   Mon, 3 Oct 2022 09:36:46 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...iv.linux.org.uk>
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

...
> * 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.
chroot() inside a chroot() just constrained you further.
If fchdir() and openat() have broken that it is a serious
problem.

NetBSD certainly has checks to detect (log and fix)
programs that have (or might) escape from chroots.

unshare() seems to create a 'shadow' inode structure
for the chroot's "/" so at least some of the tests
when following ".." fail to detect it.

I also thought containers relied on the same scheme?
(But I'm too old fashioned to have looked into them!)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)