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
| ||
|
Message-ID: <592405fa149247f58d05a213b8c6f711@AcuMS.aculab.com> 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)
Powered by blists - more mailing lists