Ubuntu Hardy chrooted bind9 fails to start

[Djamu]

Preparing to move my server to LTS Ubuntu Hardy, just testing using vmware
I've found a weird issue while chrooting bind. ( following The Perfect Server Setup )
So I guess this will popup sooner or later anyway...

What I did so far -all as root-:

apt-get install bind9
/etc/init.d/bind9 stop

changed 1st line of /etc/default/bind9

vim /etc/default/bind9
> changed first line to > OPTIONS="-u bind -t /var/lib/named"

creating some directories & a link to move /etc/bind to /var/lib/named/etc/bind
creating null & random devices
fixing permissions

mkdir -p /var/lib/named/etc
mkdir /var/lib/named/dev
mkdir -p /var/lib/named/var/cache/bind
mkdir -p /var/lib/named/var/run/bind/run
mv /etc/bind /var/lib/named/etc
ln -s /var/lib/named/etc/bind /etc/bind
mknod /var/lib/named/dev/null c 1 3
mknod /var/lib/named/dev/random c 1 8
chmod 666 /var/lib/named/dev/null /var/lib/named/dev/random
chown -R bind:bind /var/lib/named/var/*
chown -R bind:bind /var/lib/named/etc/bind

fixed /etc/default/syslogd

vim /etc/default/syslogd
> SYSLOGD="-a /var/lib/named/dev/log"

This has always worked in the past.. but doesn't on Hardy 8.04

if I try to start > /etc/bind9 start it simply fails
stopping it >

 rndc: connect failed: 127.0.0.1#953: connection refused

vim /var/log/syslog reveals

Mar 25 08:06:57 hardy-server named[11824]: starting BIND 9.4.2 -u bind -t /var/lib/named
Mar 25 08:06:57 hardy-server named[11824]: found 1 CPU, using 1 worker thread
Mar 25 08:06:57 hardy-server named[11824]: loading configuration from '/etc/bind/named.conf'
Mar 25 08:06:57 hardy-server named[11824]: none:0: open: /etc/bind/named.conf: permission denied
Mar 25 08:06:57 hardy-server named[11824]: loading configuration: permission denied
Mar 25 08:06:57 hardy-server named[11824]: exiting (due to fatal error)
Mar 25 08:06:57 hardy-server kernel: [ 9136.933011] audit(1206428817.898:3): operation="inode_permission" request_mask="r::" denied_mask="r::" name="/var/lib/named/etc/bind/named.conf" pid=11825 profile="/usr/sbin/named" namespace="default"

anybody any idea ?, I've checked permissions, locations.... and with feisty / gutsy this just worked...

thx..

[topdog]

As you can see from the error messages this is a permissions issue the config file can not be read by named.

[topdog]

Come to think of it looking at the last line it could be apparmor that is blocking access to the file.

[Djamu]

Woohoo cool that was it, after purging this package it worked, obviously this is not the way to do this, but now I know for certain... apparmor is something new on ubuntu, wasn't aware of it... I'll take a look in the Suse community for a decent manual

thank you,

[Djamu]

here's the fix, don't know if it makes much sense to chroot and use apparmor at the same time.. guess there's no harm either...

follow above described procedure & end with

vim /etc/apparmor.d/usr.sbin.named

and change marked lines

# vim:syntax=apparmor
# Last Modified: Fri Jun  1 16:43:22 2007
#include <tunables/global>

/usr/sbin/named {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_chroot,

  # Dynamic updates needs zone and journal files rw. We just allow rw for all
  # in /etc/bind, and let DAC handle the rest > moved to /var/lib/named/etc/bind
  /var/lib/named/etc/bind/* rw,

  /proc/net/if_inet6 r,
  /usr/sbin/named mr,
  /var/cache/bind/* rw,
  /var/lib/named/var/run/bind/run/named.pid w,
  # /var/run/bind/run/named.pid w,
  # support for resolvconf
  /var/lib/named/var/run/bind/named.options r,
  # /var/run/bind/named.options r,

# add also following lines thanks to Spezi2u 
  /var/lib/named/dev/null rw,
  /var/lib/named/dev/random rw,


}

don't forget to (re)start services

/etc/init.d/sysklogd restart
/etc/init.d/apparmor start
/etc/init.d/bind9 start

[topdog]

I wonder why they would ship a policy that does not work. Am not sure if it will work in the chroot, as most MAC systems use the real file path test if you can and let us know.

[Djamu]

Originally Posted by topdog

I wonder why they would ship a policy that does not work. Am not sure if it will work in the chroot, as most MAC systems use the real file path test if you can and let us know.

Well the policy did work until I moved & chrooted it... so IMHO that makes sense .. because that's part of what apparmor is supposed to do ( my rudimentary understanding of creating a hat )
I used a symbolic link for all libraries that have path's hard coded ( if I understand you correct ), Bind seems to behave properly so until now all is well.

I still don't know if there's a point in using chrooting & apparmor at the same time, as it might as well weaken security instead of additional hardening...

If someone knows of a deprecated package with known weaknesses I might be able to test those in this kind of environment ( why aren't there 48h days ).

But before that I have to solve another issue with compiling the ISPconfig package, as it's complaining about wrong syntaxes in an empty httpd.conf ...

[Spezi2u]

Thanks for the help on apparmor. I have noticed that bind will still not access the random device and apparmor seems to go out of the chroot jail and take the old one so I have just added two lines at the end to

/etc/apparmor.d/usr.bin.named

[...]
  /var/lib/named/dev/null rw,
  /var/lib/named/dev/random rw,
[...]

that seemed to do the trick. Bind starts perfectly now.

[Djamu]

K thx, didn't notice yet ( stopped working on it ), pretty busy debugging a bogus driver..
I'll add it to the howto...

[omni]

I just ran into this problem as well after upgrading to 8.04LTS also and this fixed it perfectly!

Thanks for the info guys!