bind9 in a chroot jail - necessary or not?

I always used to keep my bind9 installation in a chroot jail. Now I upgraded my vServer and have to install bind9 over again. Due to the virtualization solution my hosting provider uses, I cannot create devices (/jail/dev/random and /jail/dev/null) myself, and my hosting provider charges 20€ for it.

To quote Adrian Bunk,

Incompetent people implementing security solutions are a real problem. 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.

As far as I've understood this discussion, running software as root in a chroot is worthless, as the root user can always escape the jail. But if I run it as an unprivileged user, it should still provide additional security, correct?

To sum up, is it worth 20€ to put bind9 in a chroot jail?

Solution 1:

Well, lkml discussion is about root user escaping chroot jail and bind never runs in the chroot jail using root privileges. So, an attacker still have to find an exploit to escape chroot jail if he or she compromises the bind process.

Solution 2:

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"