[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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