I would like a definitive answer as to why this practice should be pursued with services that are exposed to potentially hostile network(s) (i.e. the Internet). As I understand it, there is a method for breaking out of a chroot jail, so if there is no real value to this security measure, then why are some installations still pursuing it?
You should never consider a chroot a complete security feature. While is makes attack harder, if you do manage to get some control inside the chroot, it is fairly easy to break out of. There's a method involving chrooting to a parent directory (..) More info here. The reason that chroot gives some security benefit is that many of the applications that a hacker might expect to have around just won't be there. If given the choice between something being chrooted or not chrooted, I'd pick the chrooted option.
A better approach would be something like BSD's jail, Solaris's zones or some virtualisation technology like KVM or Xen. These approaches take the same compartimentalisation idea that chroot does and makes them stronger. You could also look at something like SELinux, but this is slightly more complicated, and therefore prone to mistakes.
As I understand it, there is a method for breaking out of a chroot jail (...) then why are some installations still pursuing it?
You can say the same thing about passwords. The point is that quite often securing some resources means placing so many obstacles on intruder's way to force him to give up before reaching the target. You can't rely on a single method to secure given resource. Furthermore, chrooting gives you more control over an application you're running. You can restrict file system resources this app have access to.
Yes it does.
- If your daemon or whatever is providing the service does not run as root then even a hole in that daemon is isolated from the rest of the system.
- If your OS can restrict operations that can be done while chroot()ed, it's even better. grsec-patches to Linux for example can remove ability of the root user inside a chroot to break out, or create /dev-nodes inside the chroot
If, however, you get an exploitable kernel bug (or just a root hole if not grsec or BSD jails) inside the chroot, then the whole system is owned. Not so if you run a real virtualizer (such as VMWare, but NOT BSD jails. They don't help since they use the same kernel for all "systems").
So yes, it adds a security layer, if used correctly.
So if there is no real value to this security measure, then why are some installations still pursuing it?
There may not be much security gained, but in some cases you make the system easier for the user. If they are not distracted by all the other stuff they don't need to see, they may find the system easier to use.
I find chroots to be way to complicated and have never been able to install one. One could argue that if I had been able to do so, I would find great interest in it but I still haven't.
I think that isolating your services in virtual machines (on Xen of course, but VMWare will work too if you insist :-P ) is a much better idea considering the computing power available these days. Virtual machines also have the huge advantage of being really easy to backup/migrate which chroots do not have. You also have comprehensive interface for managing VMs, which you definently don't have for chroots.
Chroot adds a lot of security benefits and you can only break it if you are root. So you are raising the bar for what an attacker needs to do.
Plus, chroot provides an application isolation, while virtualization provide operating system separation. So you can run, for example, apache inside chroot on a virtual machine.