bind chrooted, logging and SELinux = suffering

[Jason Vas Dias]

On Wed, 2005-06-01 at 10:06, Mariano Cunietti wrote:
> Hi,
> I'm running Bind 9.2.4 chrooted (bind-chroot.rpm, directory
> /var/named/chroot/) on a RedHat 4EL server, with SELinux enforced.
> After a lot of trouble (solved!) with slave zone transfers (take a look
> to message "Solution to slave zone transfer problem", by Jason Vas Dias
> <jvdias at redhat.com>), I get always the same error while trying to log to
> other file than /dev/log:
> 
> logging {
>         channel seclog {
>         file "/var/log/dns-sec.log" versions 5 size 1m;
>         print-time yes; print-category yes;
>         };
>         category xfer-out { seclog; };
>         category security { seclog; };
>         category lame-servers { null; };
> };
> 
> # ls -l /var/named/chroot/
> drwxrwxr--  2 root named 4096 May 31 14:50 dev
> drwxrwx---  2 root named 4096 Jun  1 15:57 etc
> drwxrwx---  6 root named 4096 May 31 15:18 var
> 
> # ls -l /var/named/chroot/var
> drwxrwx---  2 named named 4096 May 31 15:18 log
> drwxrwx---  4 root  named 4096 Jun  1 15:19 named
> drwxrwx---  3 root  named 4096 May 30 16:03 run
> drwxrwx---  2 named named 4096 May 31 17:31 tmp
> 
> # ls -l /var/named/chroot/var/log
> -rw-rw----  1 named named 0 May 31 15:18 dns-sec.log
> 
> # tail -f /var/log/messages
> 
> Jun  1 15:40:03 dexter named[29371]: loading configuration from
> /etc/named.conf'
> Jun  1 15:40:03 dexter named[29371]: logging channel 'seclog' file
> '/var/log/dns-sec.log': permission denied
> Jun  1 15:40:03 dexter kernel: audit(1117633203.103:0): avc:  denied  {
> append } for  pid=29372 exe=/usr/sbin/named name=dns-sec.log dev=md2
> ino=3801110 scontext=root:system_r:named_t 
> tcontext=root:object_r:named_conf_t tclass=file
> Jun  1 15:40:03 dexter named: named reload succeeded
> 
> 
> I think SELinux is causing a lot of problems. How can I disable all of
> these constraints without shutting it off? How is it possible that
> RedHat is not concerned abot an official RPM *NOT* working because of
> conflicts with other default configurations??
> Did anybody else got these pains in the a*s?
> 
> I'm really disgrunted. How can we encourage security when the only way
> out is no-security??
> 
> Thanks
> 
If you have problems with the Red Hat BIND distribution, please report
them through bugzilla.redhat.com .

By default, Red Hat ships BIND with maximum security protection enabled,
to counter known security vulnerabilities as mandated by our security
response team.

You are free to disable the SELinux BIND security protection completely:

 # chcon -R system_u:object_r:sbin_t /usr/sbin/named /usr/sbin/rndc
 # chown -R named:named /var/named

A better solution would be to work within the SELinux named policy for
new files you want bind to create / write - for example, to enable
writing to a /var/named/chroot/log directory as in your case:

 # mkdir /var/named/chroot/log
 # chown named:named /var/named/chroot/log
 # chcon -R system_u:object_r:named_cache_t /var/named/chroot/log

Also, bear in mind that the need for the chroot environment is 
removed by use of SELinux: SELinux policy is far more secure than
the chroot environment. You can "rpm -e bind-chroot" and then use
SELinux to enforce security for the /var/named directory.

I've attached the "NOTES" section from the named man-page in 
the latest version of the Red Hat BIND distribution which
explains SELinux BIND administration issues:

NOTES
       Red Hat SELinux BIND Security Profile:

       By default, Red Hat ships BIND with the most secure SELinux policy that
       will not prevent normal BIND operation and will prevent exploitation of
       all known BIND security vulnerabilities . See the selinux(8)  man  page
       for information about SElinux.

       It is not necessary to run named in a chroot environment if the Red Hat
       SELinux policy for named is enabled. When enabled, this policy  is  far
       more  secure than a chroot environment. Users are recommended to enable
       SELinux and remove the bind-chroot package.

       With this extra security comes some restrictions:

       By default, the SELinux policy does not allow named to write any master
       zone  database files. Only the root user may create files in the $ROOT-
       DIR/var/named zone database file directory (the options { "directory" }
       option), where $ROOTDIR is set in /etc/sysconfig/named.

       The  "named"  group  must  be  granted read privelege to these files in
       order for named to be enabled to read them.

       Any file created in the zone database file directory  is  automatically
       assigned the SELinux file context named_zone_t .

       By  default,  SELinux  prevents  any  role  from modifying named_zone_t
       files; this means that files in the zone database directory  cannot  be
       modified by dynamic DNS (DDNS) updates or zone transfers.

       The  Red  Hat BIND distribution and SELinux policy creates two directo-
       ries where  named  is  allowed  to  create  and  modify  files:  $ROOT-
       DIR/var/named/slaves  and $ROOTDIR/var/named/data. By placing files you
       want named to modify, such as slave or DDNS updateable zone  files  and
       database  / statistics dump files in these directories, named will work
       normally and no further operator action is  required.  Files  in  these
       directories  are  automatically  assigned the ’named_cache_t’ file con-
       text, which SELinux allows named to write.

       You can enable the named_t domain  to  write  and  create  named_zone_t
       files  by use of the SELinux tunable boolean variable "named_write_mas-
       ter_zones", using the setsebool(8) command or  the  system-config-secu-
       rity  GUI  .  If  you  do this, you must also set the ENABLE_ZONE_WRITE
       variable in /etc/sysconfig/named to 1 / yes to  set  the  ownership  of
       files  in  the $ROOTDIR/var/named directory to named:named in order for
       named to be allowed to write them.