Unit 3 Discussion: Regular DNS vs Chroot (jail)

What's a "Jail"? Though the utility of a nameserver is probably clear to most people reading this tech tip, the concept of "jail" may not be: we've been asked to elaborate. A "jail" is a software mechanism for limiting the ability of a process to access resources outside a very limited area, and it's done with security in mind. A nameserver often talks to the outside world, and time has shown that "the public internet" is a very hostile environment. Should a flaw in BIND be discovered, it could be exploited by one located anywhere on the planet: by isolating the process inside a jail, this restricts the harm that can be done to a compromised system. A jail is created using the chroot() system call (named for "change root"), and it's given a directory name as a parameter. Once this call is made, the root - the top of the directory tree - for this process is changed from / to the directory given, and there is no way for the process to get outside this area. We typically use /chroot/named to jail our nameservers, but we'll note that the "chroot" in the directory name is just a convention: this is not required (e.g., "/usr/local/named" would make a fine jail location too). By itself, this won't prevent some flaw in BIND from being exploited, but the worst that happens is that the nameserver is compromised: it can't be leveraged to taking over the whole system. In this way it's more of a general safety precaution providing defense in depth. Much more information on chroot jails can be found in our Linux Magazine article: Go Directly to Jail - Secure Untrusted Applications with Chroot Pick up the source Get the source at the Internet Software Consortium, and the home page for BIND is http://www.isc.org/products/BIND/. These instructions were written for 9.1.2 on a Red Hat Linux 6.2 system, and we'll try to keep them updated as we upgrade our and customer systems. We generally try to keep running the latest stable versions - we're not generally too adventurous with beta. Our practice is to keep our own build stuff under a /source tree, and to unpack individual sources under it. # cd /source # gtar -xzvf bind-9.1.2.tar.gz This unbundles everything into a subdirectory with the full name of the package, and the next step is to to configure and build it. Configure and build The BIND instructions say to simply run ./configure, but under Linux a couple of additions are required. For many years, we have recommended disabling thread support, because in 2.2 kernels, chroot jailing did not work properly. We have never been brave enough to attempt it with more recent kernels, but we've been getting reports that threading works fine in 2.6. In addition, BIND can support IPv6, the next generation IP addresses (current version is IPv4). BIND typically probes for IPv6 support at runtime, but since we are quite sure that we really don't need this on our networks, we disable it entirely as a safety measure. NOTE: we prefer to remove any existing nameserver installations (especially those provided by the operating system) before installing the new one. This avoids problems with older versions of key binaries lying around and sometimes being at the wrong point in the command-search $PATH. Under Red Hat Linux (for instance), this means removing three packages before doing installations. # rpm -e bind bind-utils caching-nameserver Finally, we want everything installed into the /usr/local hierarchy, so we provide the installation prefix. This said, configuration and installation is quite simple: # cd /source/bind-9.1.2 # ./configure --prefix=/usr/local --disable-ipv6 # make # make install This takes about 15 minutes on a dual-CPU 200 MHz Pentium Pro machine and about three minutes on a 1 GHz Pentium III, and it installs around 200 files under /usr/local. Most of them are #include files for C language programming, and only about a dozen are really needed for a BIND installation. See the complete file list at the end of this document. Build and configure the jail Creating the actual jail itself is much easier than for BIND 8 because so much trash is not required - it's just tremendous. In particular, none of the shared libraries or named binary files are required to live in the jail, and this makes it easier and more secure for us. For more details on our thoughts on chroot operations, see our more detailed tech tip Best Practices for UNIX chroot() Operations The initial steps to configure the jail are: create initial named user and group # groupadd named # useradd -g named -d /chroot/named -s /bin/true named # passwd -l named "lock" the account Remove all the login-related trash under the newly-created home directory # rm -rf /chroot/named Re-create the top level jail directory # mkdir -p /chroot/named # cd /chroot/named create the hierarchy # mkdir dev # mkdir etc # mkdir logs # mkdir -p var/run # mkdir -p conf/secondaries create the devices, but confirm the major/minor device numbers with "ls -lL /dev/zero /dev/null /dev/random" # mknod dev/null c 1 3 # mknod dev/zero c 1 5 # mknod dev/random c 1 8 copy the timezone file # cp /etc/localtime etc Noticeably absent are any ownership/permissions issues: this is deliberate. We'll get to it shortly. Note that the ls command used to verify the major/minor device numbers includes the -L parameter - this follows symbolic links and is required on some platforms such as Solaris. Construct the configuration files The named.conf configuration is central to named operation, and we'll go through creating it step by step. Though these files can get very complex, our first efforts will be for a minimal caching-only nameserver just to get the whole end-to-end process working correctly. Then we'll retrofit to add in needed features such as local domains and access controls. The named.conf file lives in the jail's etc directory, which makes the full path /chroot/named/etc/named.conf. We usually create a symbolic link to make this visible to the rest of the system at /etc/named.conf. # ln -s /chroot/named/etc/named.conf /etc/named.conf Note - we're creating a symbolic link to a file that does not yet exist - this is confusing. But when we edit the file (the next step), it is created properly. Now, using your favorite editor, create the first version of the etc/named.conf file. We suspect that some of these parameters are not strictly necessary, as the defaults will do, but we feel that being explicit will make the daemon easier to debug for the new administrator (less searching for key files). options { directory "/conf"; pid-file "/var/run/named.pid"; statistics-file "/var/run/named.stats"; dump-file "/var/run/named.db"; # hide our "real" version number version "[secured]"; }; # The root nameservers zone "." { type hint; file "db.rootcache"; }; # localhost - forward zone zone "localhost" { type master; file "db.localhost"; notify no; }; # localhost - inverse zone zone "0.0.127.in-addr.arpa" { type master; file "db.127.0.0"; notify no; }; Notice that the directory keyword says /conf, not /chroot/named/conf - this is intended. When running the nameserver inside the chroot jail, all the paths are relative to the top of the jail at /chroot/named. This configuration refers to three additional files -- db.rootcache, db.localhost and db.127.0.0 -- and they are all created in the /chroot/named/conf directory. db.rootcache is a...

Buy now to view the complete solution