I'm playing with bind and started wondering why this software is, for example, in CentOS running in chroot. Don't misunderstand me, I know what bind is and what chroot (jail) is for. But my main question is that is bind running whithout chroot so very unsecure?

Is it really harmful to set it up without a jail(more then any other service or software). In systems there are many proccesses running without chroot and I think compromise of any of them is very dangerous but what makes named more dangerous then other software running without chroot ?

  • 1
    To add to the question: How is this affected by modern use of virtual machines? For any moderately sized deployment it's increasingly likely to dedicate a VM to each task, so it has no other data/applications on it. Is there still a real benefit in chrooting? – gregmac Dec 5 '13 at 15:13
  • 3
    A chroot is not a jail. A jail is something specific on BSD. If you want the equivalent you should be looking at LXC – Zoredache Dec 5 '13 at 17:19

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.


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.



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.

  • The original developer of chroot point blank said he never intended chroot for security use. As for major application developers implementing faulty security... ARM, Intel, and AMD all recently discovered a security flaw in their hardware going back all the way to the Pentium era. SSLv2, SSLv3, TLSv1, and TLS1.1 all have critical security flaws despite TLSv1.1 still being an industry standard for OpenSSHd, Apache, Dovecot, OpenVPN... pretty much everyone you mentioned. And all of them still default to using SSL Compression which undermines even the latest TLSv1.2 and TLSv1.3 standards. – Cliff Armstrong Jan 24 '18 at 13:10
  • Developers (the successful ones, at least) ultimately balance between convenience and security... and they often favor convenience over security. These applications support chroot for "security" because their users demand it. Their users demand it because of the common misconception that it provides meaningful security. But, in spite of your appeal to the masses/authority argument, this is demonstrably not true. – Cliff Armstrong Jan 24 '18 at 13:13

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.

  • You're correct its much improved. Basically, bind8 was a nightmare; bind9 isn't. E.g., if you search the NVD, I don't see any remote code execution bugs listed, at least since 2010 (as far back as the search went): web.nvd.nist.gov/view/vuln/… ... plenty of DoS bugs, and also a few information disclosure bugs (e.g., disclosing internal zones). – derobert Dec 9 '13 at 18:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.