DNS, Apache, SELinux, Fedora Core 3

I ran into a problem when trying to run Bind on as a secondary/slave server on Fedora Core 3.

Fedora Core 3 contains SELinux. SELinux adds an additional layer of access control on top of the traditional Unix owner, group, and world protection bits.

You can run into this problem if you run Bind and your named.conf file specifies a slave zone and also specifies a file into which the downloaded zone file should be placed.

Suppose you have an entry in your named.conf file that looks something like this:

zone "example.com" {
    type slave;
    file "2nd/db.example.com.2nd";
    masters {
        192.168.1.1;
    };
};

You can get an error in your logs that looks something like the following:

Jan 16 20:40:26 p3 kernel: audit(1105936826.400:0): avc:  denied  { write } for  pid=7216 exe=/usr/sbin/named name=2nd dev=md4 ino=491657 scontext=root:system_r:named_t tcontext=root:object_r:named_zone_t tclass=dir
Jan 16 20:40:26 p3 named[7215]: transfer of 'example.com/IN' from 192.168.1.1#53: failed while receiving responses: permission denied

Apparently someone decided that the downloading of zone files can be a security hole and should be opened only through the explicit action of the system administrator.  Unfortunately nobody bothered to tell the system administrator how to do this.

Here's how I fixed the problem.  As superuser (root) I ran the following command:

setsebool -P named_write_master_zones true

While on the subject of SELinux, I also ran into another access failure when trying to put my web server's DocumentRoot onto a mounted filesystem rather than in /var/www.

In my case I created a new RAID volume that I mount as /vol0 and wanted my DocumentRoot to be in /vol0/www.

I had to run two commands (as root) to establish the correct security contexts.  The second of these commands was needed because the root of that file system was unlabled, i.e. had no security labels.  I had to use the form of the command with the elements of the security context joined by colons rather than using the -t -r and -u options because the chcon command doesn't realize that it has enough information to go forward when all three options are present.

chcon -R -t httpd_sys_content_t /vol0/www
chcon system_u:object_r:httpd_sys_content_t /vol0/

I don't know if these are the proper solutions, but they did seem to work.

Posted by karl at January 17, 2005 2:55 PM