| |||||||||||||
What chroot() is really forWhat chroot() is really forPosted Oct 5, 2007 20:29 UTC (Fri) by wahern (subscriber, #37304)In reply to: What chroot() is really for by jond Parent article: What chroot() is really for
That chroot doesn't work? I can also point you to many advisories that have shown that chroot also contained an exploit. OpenSSH, BIND, Apache (OpenBSD), OpenNTP, djbdns, and qmail all use chroot, and the use of chroot has mitigated the impact of serious and widespread code exploits.
chroot is not _the_ answer. In all this debate, either here or on LKML, I have yet to see anybody mistakingly suggest that chroot _alone_ is a sufficient measure. All of these straw men arguments that say that chroot shouldn't be used because chroot _alone_ isn't sufficient are fallacious.
I'm only sticking to my guns because these forums are archived, and I don't want to see a student or junior engineer come to me in 10 years and say they didn't use chroot, though they trivially could have, because they were told it was useless.
(Log in to post comments)
What chroot() is really for Posted Oct 6, 2007 1:40 UTC (Sat) by wahern (subscriber, #37304) [Link] Oops. By "contained an exploit" I meant that an exploit was limited or curtailed, not that the chroot use itself was related to an exploit.(Though, like any interface, chroot could feasibly be part of an attack vector. As described in this thread, use of chroot is questionable when an administrator has to duplicate sensitive files for a chroot'd environment.)
What chroot() is really for Posted Oct 11, 2007 7:12 UTC (Thu) by gat3way (guest, #47864) [Link] Nope, chroot() works and this is its expected behavior.
And BTW there are quite a lot of ways to escape it as long as you're already a root. You can for example mount filesystems on some occasions.
Who said chroot() must provide security...against someone that already has root privilleges on that system???
|
|||||||||||||