Why running named(bind) in chroot is so important for security? Or maybe it is not?
Solution 1:
As @Some Guy mentioned you have to think about this in historical perspective.
The historical perspective was that a single piece of hardware was a dozen or so of different services under a single operating system. If one service was compromised then everything on that hardware was compromised.
With virtualization this is far less of an issue. While it is not impossible to escape out of a VM it is far from trivial. It is certainly more difficult to break out of a VM then it is for a process running with root privileges to break out of a chroot. So my bind servers are running on their own VM. There really isn't much point for a chroot in that case since damage is already limited simply by the fact that it is a VM.
A chroot is a very weak attempt at creating something like a VM. Chroots can be escaped from though by any process with root privileges. A chroot is not intended and does not work as a security mechanism. A chroot with a BSD jail, or LXC gives you OS level virtualization and does provided security features. But these days with it being so easy to spin up a new VM of an entire machine it might not be worth the effort to setup, or learn how to use the OS level virtualization tools for this purpose.
Earlier versions of bind didn't drop privileges. On Unix, only the root account can open ports below 1024, and Bind as we all know needs to listen on udp/53, and tcp/53. Since Bind starts as root, and doesn't drop privileges any compromise would mean the entire system could be compromised. Almost any software these days will start open their sockets and do any other stuff that requires root privileges then they will change the user they are running as to a non-privileged account. Once the privileges are dropped the impact of being compromised is a lot lower to the host system.
Solution 2:
The other answers are pretty good but fail to mention the concept of security in layers. Every layer of security you add to your system is another layer that an adversary must overcome. Putting BIND in a chroot adds one more obstacle.
Say there is an exploitable vulnerability in BIND and someone is able to execute arbitrary code. If they're in a chroot, they need to break out of that before getting to anything else in the system. As mentioned root privileges are required for chroot-breaking. BIND doesn't run as root, and there are supposed to be minimal tools available in the chroot, further limiting options and essentially leaving only system calls. If there's no system call to escalate privileges then the adversary is stuck looking at your DNS records.
The aforementioned situation is somewhat unlikely as SomeGuy mentions, BIND has quite few vulnerabilities these days and they're mostly restricted to DoS type scenarios rather than remote execution. That said, running in a chroot is the default configuration on quite a few OSes, so it's unlikely to take any effort on your part to keep the ever-so-slightly increased security.
Solution 3:
preamble
i keep hearing people reiterate misconceptions from all over the internet.. thus, i will try to give some clarification
first off; how many accidental discoveries have there been, which simply.. due to cause and effect, ended up being used for something other than its intended purpose?
what was, and what is, a Chroot jail
Chroot was initially designed to change the root directory for the process or user (great for compiling software from unknown sources). this provided security to the base system, as well as a quick test bed appliance, including easy clean-up. years have went by since, and it's concept and implied uses have certainly changed, likewise.
chroot has been used effectively, and is directly in the code base for several programs and libraries (i.e. openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot, and so much more). assuming that all these mainstream applications have implemented faulty security solutions is just not true
chroot is a solution to file system virtualization: nothing less, nothing more. the assumption that you can easily break out of a chroot is also not true... as long as you adhere to the guidelines of running processes inside of the chroot jail.
some steps to secure your chroot jail
i.e. do NOT run processes as ROOT. this could open up a root escalation vector (which is also true inside or outside the chroot). do not run a process inside the chroot, using the same user as another process outside the chroot. separate each process and user into his own Chroot in order to limit attack surfaces, and provide privacy. only mount necessary files, libraries, and devices. lastly, chroot is NOT a replacement for base system security. secure the system in its entirety.
another important note: a lot of people think that OpenVZ is Broken, or that it's not equal in comparison to full system virtualisation. they make this assumption because it is essentially a Chroot, with a process table that has be sterilized. with security measures in place on hardware and devices. most of which you can implement in a chroot.
not every admin has the level of knowledge needed to secure all the necessary kernel parameters on a dedicated server or under full system virtualization. this means that deploying OpenVZ means that your customers will have much less attack surface to try and cover and secure before deploying their applications. a good host will do a good job securing these parameters, and it in turn, this is better for not only everybody on the Node, or in the data-center, but for the internet as a whole...
as stated, the chroot provides file system virtualization. you must ensure that there are no setuid executables', insecure applications, libraries, dangling ownerless symlinks, etc. if the attacker COULD compromise bind, they would need to scour the virtual file system for something to buffer overrun, play with file descriptors, or in some other way compromise something residing inside the chroot- escaping the jail usually through privilege escalation or injecting his or her payload into the base system.
if this happens, its usually the result of a bad update, zero day exploit, or idiomatic human error.
why chroot is still used, as opposed to full system virtualization
consider this scenario: you are running a Virtual Private Server, with the host node running OpenVZ. you simply can not run anything that works on the kernel level. this also means you can not use operating system virtualization to separate processes, and provide additional security. thus, you MUST use chroot for this purpose.
moreover, chroot is sustainable on any system, regardless of resources available. simply put, it has the very least overhead of any virtualization type. this means it is still important on many low end boxes.
consider another scenario: you have apache running inside a virtualized environment. you want to separate each user. providing a virtualized file system through a chroot add on to apache (mod_chroot, mod_security, etc) would be the best option to ensure utmost privacy between end users. this also helps prevent intel gathering, and offers yet another layer of security.
simply put, it is important to implement security in layers. Chroot potentially being one of them. not everybody and every system has the luxury of having access to the Kernel, therefore, chroot STILL serves a purpose. there are a variety of applications in which full system virtuaisation is essentially overkill.
In response to your question
i dont particularly use CentOS, but i know that Bind now drops its privileges before operations. i would assume, however, that bind is chrooted due to its history of attack vectors and potential vulnerabilities.
also... it makes more sense to automatically chroot this application, than not, because not EVERYONE has access to full system/operating system level virtualization. this in turn, and in theory, helps provide security to the CentOS user base:
operating system providers simply do not go around assuming every one is running the same system. this way, they can help provide an additional layer of security at large...
there is a reason why so many applications use this, and why obviously your OS does by default: because it IS used as a security feature, and it DOES work. with careful preparation, as previously stated, it is yet another hurdle the potential attacker must overcome- most of the time, restricting damage to done to only the chroot jail.
Solution 4:
This is partially due to historical reasons, when older versions of Bind had severe, frequent security vulnerabilities. I haven't really kept up to date on the subject, but I'd wager that it's much improved since the bad ol' days.
The other reason, the more practical one, is just that it's typically deployed in an Internet-facing role, and as such, it's open to more attacks, probing, and general mischief.
Therefore, as is often the rule of thumb in security matters: better safe than sorry, particularly as the effort of chroot-ing it is relatively little.