GitLab

Summary

Recent versions of named have a new behavior of creating temporary files in the /var/named directory, instead of within a designated temporary directory.

This behavior triggers SELinux denials on Linux systems that run SELinux, such as Fedora, because it is not expected that named will need to write to the /var/named directory in scenarios where DDNS is not being used.

A work-around recommended by Red Hat (1) is to set the named_write_master_zones SELinux boolean to true, which will cause SELinux policy to ignore attempts to write into the /var/named directory. (More specifically, it will permit named to create/write/unlink files in a directory with the named_zone_t file context.)

But this isn't a good work-around for sites that are not using DDNS. If I'm not using DDNS, I have every reason to expect that named attempting to create a file in a directory with the named_zone_t label represents a potential security threat (e.g., a successful remote code execution attack against named). This is precisely the type of behavior I want SELinux to block.

Thus, named should not create temporary files in the /var/named directory. If named needs to create temporary files, at least on Unix platforms, named should create temporary files in the /tmp directory. If this is unacceptable for some reason (e.g., because named intends to issue a rename(2) call on the temporary file and does not wish to receive EXDEV), then named should use a dedicated temporary directory within /var/named (e.g., /var/named/tmp) to create temporary files. This temporary directory can be labeled with an appropriate SELinux file context (e.g., named_tmp_t) such that SELinux policy can permit named to create temporary files in this directory, but not in /var/named.

I fully admit that dealing with SELinux is annoying. But many sites are required to run SELinux in enforcing mode in order to satisfy various compliance restrictions. And the effort required to help enable SELinux best practices is minimal.

(1) https://bugzilla.redhat.com/show_bug.cgi?id=1707910

BIND version used

BIND 9.11.6-P1-RedHat-9.11.6-2.P1.fc29 (Extended Support Version) <id:520073a>
running on Linux x86_64 5.0.14-200.fc29.x86_64 #1 SMP Thu May 9 10:46:15 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-geoip' '--with-libidn2' '--enable-openssl-hash' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=no' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' 'CPPFLAGS= -DDIG_SIGCHASE' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 8.3.1 20190223 (Red Hat 8.3.1-2)
compiled with OpenSSL version: OpenSSL 1.1.1b FIPS  26 Feb 2019
linked to OpenSSL version: OpenSSL 1.1.1b FIPS  26 Feb 2019
compiled with libxml2 version: 2.9.8
linked to libxml2 version: 20908
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled

Steps to reproduce

Configure a recent version of named to serve a static zone, then start named and issue queries against that zone.

If you trace the named process, you will see it creating temporary files in the /var/named directory.

What is the current bug behavior?

named will create temporary files in the /var/named directory.

What is the expected correct behavior?

named should create temporary files in the /tmp directory or /var/named/tmp directory.

Relevant configuration files

This should be reproducible with any named configuration that serves static zones.

Relevant logs and/or screenshots

None at this time.

Possible fixes

I've been searching through the past few months' of commits, to see if I can identify the exact commit that caused the change, but I don't see anything obvious.

I suspect that what has happened is that named previously did not create temporary files unless DDNS was in use, but a recent feature or change has caused named to create temporary files even when named is serving nothing but static zones.

Meaning, I suspect this behavior doesn't represent a change in how named creates temporary files; I suspect named has always used /var/named for temporary files. The change is probably that named now creates temporary files in normal operation even when DDNS isn't in use. So this is why I am seeing this particular behavior from named now.