Mon, 28 Jun 2010

BIND 9 DNS on Ubuntu with AppArmor

Like many people I run Ubuntu on a number of servers with DNS being just one of the services provided. Bind 9 has worked extremely well to date, though I recently came across a conflict between AppArmor (note American spelling) and bind which resulted in slave domains not being replicated correctly. This happened on my systems some time on or after 2009-07-29 (and I'm only getting around to writing up the blog post now... I know...) If you see lines similar to the following in the output of dmesg, or in your system log, you may have the same problem:
audit(1234567890.462:15891): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::" name="/etc/bind/zones/slave/tmp-bkTe208LbH" pid=123 profile="/usr/sbin/named" namespace="default" audit(1234567890.460:15892): type=1503 operation="inode_create" requested_mask="w::" denied_mask="w::" name="/etc/bind/zones/slave/tmp-3VUN2uHFUI" pid=123 profile="/usr/sbin/named" namespace="default"
To explain briefly what this means: AppArmor is an extra layer of security which effectively makes sure that system programs are allowed only limited access to the system, even though they may run as root. This helps significantly in the case of a root escalation vulnerability being discovered, since if AppArmor is correctly configured your system is somewhat compartmentalised so damage should be limited. Without this, a root privilege escalation in a daemon would allow full read and write access to the entire system, with predictably bad results. Permissions for various daemons under AppArmor are configurable in files under /etc/apparmor/ and /etc/apparmor.d/ (on an Ubuntu system at least.)

Under Ubuntu it appears that AppArmor is misconfigured for BIND 9, specifically with regard to the default setting that slave zones - where your DNS server is acting as a secondary DNS server for some domain(s) - are stored under /etc/bind9/zones/slave/. From the log lines above it's clear that AppArmor is disallowing writes to this location for BIND, with the result that secondary / slave zones can never be updated. This is a bad thing.

Fortunately, there is an easy solution. Either update your BIND config to write slave zone files somewhere else, or update AppArmor to allow BIND to write to the slave zones directory. I chose the latter, accomplished by adding the following line to /etc/apparmor.d/usr.sbin/named
/etc/bind/zones/slave/** rw,
This allows bind to read and write to the slave directory, enabling it to create the files it needs to store updated zones coming via AXFR transfers from master DNS servers. You can test by running rndc reload and watching the syslog and file timestamps in the slave directory. You should also no longer see log writings with the denied_mask="W::" key-value pair as above.

Thanks to alphageek for the first clue as to what was going on and hopefully this blog entry will provide a more secure fix for the problem.

posted at: 13:31 | path: /technical | permanent link to this entry