i realize that this is a little late, but as far as a chroot not providing any "real" security goes-
this is just wrong!
the entire idea of security is that is it is provided in layers. one major tip, and the driving force behind many distributions, is to provide only the bare essentials (in terms of packages). this is because it reduces the attack surface.
a chroot, in essence, is a virtualized file system. nothing more, nothing less. however, the common misconception is that if somebody can "break bind", then they can also break out of the chroot...
but how? first off, the entire discussion about why "chroot is worthless" is that daemons running as root can be compromised to allow root privilege escalation. but most distros run Bind9 as the user named or bind.
therefore, if the attacker WAS to compromise Bind, he would have to scour the virtual file system (the chroot jail) for an exploitable application, library, setuid executable, etc, using a buffer overrun, or playing with file descriptors, etc, and delivering a payload into the base system for execution
Chroot Jails can work well, if used PROPERLY
the entire idea behind a chroot is to provide the absolute bare essentials needed to run Bind (in this instance). it is not a good idea to run multiple applications in one chroot, nor is it a good idea to place chrooted users inside a jail, along side your chrooted instance of bind. this would only increase the potential attack surface.
each application (specifically, complex forward facing services that take input, which communicate with the web directly) should reside in its own chroot jail. you could put all your users in one chroot jail, but to minimize the possible attack surface between your users (and to offer more potential privacy), the best option would to have each user in his own chroot jail, likewise.
finally, one must secure the base system in its entirety. this way, if YOU left something exploitable in the chroot jail, they have to compromise the base system before being able to do any real damage (besides to Bind and its Chroot Jail)
notice i said YOU; the only person who can fault this process (therefore making the chroot jail insecure), is yourself. sometimes bad updates or zero day exploits present holes, but most of the time its idiomatic human error.
Incompetent people implementing security solutions are a real problem.
my response to this is, while this is exactly the problem (people MISUSING chroot), it WAS adapted to be used as a security solution, and HAS been used in many solutions over the years (with great success). not everything in life ends up being used for its intended purposes, and this was obviously one of them.
a perfect example is Web Hosting Control Panels. they often use chroot to separate users. moreover, it has working implementations in titles such as Dovecot, Sendmail, Apache/Mod_Security, OpenSSH, and has been used is many libraries to provide security, one example would be pam_chroot.
a simple search would turn up the credibility of such a feature, and it is mere nonsense to base the opinion of your systems security on "a misconception of a misconception"
