I hear about needing to chroot BIND all the time. Fair enough. But what about other programs? What are the "rules" (either personal or widely accepted/established) for deciding which programs should be jailed?
When the answer isn't 'for security purposes.' See Abusing chroot.
When it was suggested that chroot is
frequently used as a security tool,
Adrian Bunk retorted, "incompetent
people implementing security solutions
are a real problem." Alan added,
"chroot is not and never has been a
security tool. People have built
things based upon the properties of
chroot but extended (BSD jails, Linux
vserver) but they are quite
different."
If you have a program that require a set/versions of libraries which is different from what is installed on your system, that would be a good candidate for a "chrooted" install.
chroot is also handy for installing different version of Linux distribution inside their own environment, without using a VM or emulator (Setting up a Debian chroot under Red Hat).
In general, you might want to use chroot for several reasons:
need for another distribution/architecture/distribution version without wanting to use OpenVZ or a virtual machine. For example, I use chroots to have both i386 and amd64 compilation environments on an amd64 machine.
restricting access to the system to users. For example, you can use chroot together with scponly to restrict the commands users have access to. This is a very limited jailing system since they still have access to the network for example.
restricting access to the system to programs. In general, you might want to do that for daemons mostly, such as bind or apache. This way, these programs will not have direct access to the system, so if an attacker could use a security breach of the program, it would not directly access the system, but instead would find himself inside the chroot. It helps enhancing the security, but it is not a guarantee that your system is secure.
It all depends on how paranoid you are. For most intents and purposes, each service should be chroot-ed for security reasons. However, it may not be feasible to do this for everything as it can get a bit tedious trying to replicate everything. Another possibility to consider for isolation purposes is the use of light-weight virtual machines like OpenVZ/VServer, which are essentially like chroot, only more so.
When the answer isn't 'for security purposes.' See Abusing chroot.
If you have a program that require a set/versions of libraries which is different from what is installed on your system, that would be a good candidate for a "chrooted" install.
chroot is also handy for installing different version of Linux distribution inside their own environment, without using a VM or emulator (Setting up a Debian chroot under Red Hat).
In general, you might want to use chroot for several reasons:
It all depends on how paranoid you are. For most intents and purposes, each service should be chroot-ed for security reasons. However, it may not be feasible to do this for everything as it can get a bit tedious trying to replicate everything. Another possibility to consider for isolation purposes is the use of light-weight virtual machines like OpenVZ/VServer, which are essentially like chroot, only more so.