default apparmor setting prevents bind from running under chroot

[mattsteven]

Binary package hint: apparmor

Easily reproducible.

1) Fresh minimal install of LTS 8.04 Hardy
2) Install bind9, verify that permissions ARE correct
3) Create the chroot (scroll down to "DNS Server" section of http://www.howtoforge.com/perfect-server-ubuntu8.04-lts-p4 to copy/paste this setup easily )
3) Edit /etc/default/bind9 changing this line to this:
OPTIONS="-u bind -t /var/lib/named"
4) Try to start bind. It will complain thusly to syslog:

none:0: open: /etc/bind/named.conf: permission denied
loading configuration: permission denied
exiting (due to fatal error)

To make bind work:
/etc/init.d/apparmor stop
/etc/init.d/bind9 start

To make it fail:
/etc/init.d/apparmor stop
/etc/init.d/bind9 restart

Unable to find sufficient documentation on apparmor to discover a workaround, that would be satisfactory as well though the next point release should make this behavior a default; for many years and for many reasons most servers have run bind in a chroot jail.

[mattsteven (matthew-matts)]

Eh, that last bit should be

To make it fail:
/etc/init.d/apparmor start
/etc/init.d/bind9 restart

[mattsteven (matthew-matts)]

And the symlink seems to be the complaint more than the chroot, I am not sure.

[Jürgen Kreileder (jk)]

Ah, come on, it's not that hard to configure apparmor for a chrooted bind. Take a look at syslog to see what apparmor prevented (probably sys_chroot and a few accesses to files). Running 'aa-logprof' should help you getting the configuration correct (after that you might want to remove the lines which are not needed for your chroot environment from /etc/apparmor.d/usr.sbin.named).

While playing with configurations it's also useful to use the complain-mode (aa-complain <profile) and switch back to enforce-mode later (aa-enforce <profile>). (Symlinks in /etc/apparmor.d/force-complain override the enforce flag).

If your named profile already was in complain mode and named didn't work properly, then there's another unrelated problem with your chroot setup.

[mattsteven (matthew-matts)]

Juergen Kreileder wrote:
> Ah, come on, it's not that hard to configure apparmor for a chrooted
> bind.

That may be but it is enough to make many people disable apparmor
completely rather than bothering to figure out how to make it work.

If you prefer the idea of not running apparmor at all, as is recommended
by Falko Timme in his popular "perfect server" setups, leave it as it
is. ( http://www.howtoforge.com/perfect-server-ubuntu8.04-lts p3#10 )

[Jürgen Kreileder (jk)]

People who are chrooting bind should definitely have a bit of administration knowledge. People who just blindly follow some tutorial without knowing what's really going on might run into problems with apparmor. But it's questionable whether those people really should fiddle about bind then.

Apparmor is a security container, if you whitelist everything, you are subverting its purpose. Ubuntu provides a setup that somewhat works with the default settings of daemons (far from perfect though). If you change the settings for a daemon, you're responsible for updating the apparmor configuration too. I doubt that your bind-chroot settings for apparmor would work for my bind-chroot.
A bind chroot isn't the only thing that requires manual apparmor configuration by the way. Other examples are mysql chroots, mysql installations with non-standard data-dirs, ... There's just no way that the default Ubuntu apparmor configuration can handle all of them.

[Derek Simkowiak (ubuntu-cool-st)]

The quote from Falko Timme that was referenced earlier is this:

Falco Timme> "In my opinion you don't need it [AppArmor] to configure a secure system, and it usually causes more problems than advantages (think of it after you have done a week of trouble-shooting because some service wasn't working as expected, and then you find out that everything was ok, only AppArmor was causing the problem)."

I'm a sysadmin and I agree with him 100%.

To Juergen, who said "Ah, come on, it's not that hard to configure apparmor...", I'd like to point out that your post suggests that all Ubuntu Server users should be forced to fully understand all of:

sys_chroot
aa-logprof
/etc/apparmor.d/usr.sbin.named
aa-complain
aa-enforce
/etc/apparmor.d/force-complain (and the "enforce flag")

As a sysadmin who actually has to meet production schedules, if I'm given the two options:

a) Learn some big, complicated security system that some dude at Canonical thinks is really great
-vs-
b) /etc/init.d/apparmor stop

...which do you think I'll choose?

I also find it ironic that AppArmor -- a supposed security layer -- is preventing him from running bind in a chroot, which is a long-established security practice.

[Jamie Strandboge (jdstrand)]

The apparmor profile contains bind9 in a similar way that the traditional chrooting does. There is no reason to chroot bind9 on Ubuntu if you are using the AppArmor profile. The reason why the profile was developed was so that all bind9 users would benefit from the enhanced security of running bind9 under confinement, and not require users to have to diverge from the standard installation and use chroot.

Users are welcome to use traditional chrooting if they prefer, and need only disable the apparmor profile by performing:
$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.named
$ ln -s /etc/apparmor.d/usr.sbin.named /etc/apparmor.d/disable/usr.sbin.named

The first unloads the profile from the kernel, and the second disables the profile on boot.

[wlraider70 (wlraider70)]

poor decision. I have had to totally disable apparmor until i figure out the profiles.

[D J Gardner (djgardner)]

for what it's worth, here is my /etc/apparmor.d/local/usr.sbin.named:

   /var/bind9/chroot/etc/bind/** r,
   /var/bind9/chroot/var/lib/bind/** rw,
   /var/bind9/chroot/var/lib/bind/ rw,
   /var/bind9/chroot/var/cache/bind/** rw,
   /var/bind9/chroot/var/cache/bind/ rw,
   /var/bind9/chroot/var/run/named/named.pid w,
   /var/bind9/chroot/var/run/named/session.key w,
   /var/bind9/chroot/dev/random r,
   /var/bind9/chroot/dev/log w,
   /var/bind9/chroot/dev/null rw,

# support for resolvconf
   /{,var/,var/bind9/chroot/}run/named/named.options r,
   /var/bind9/chroot/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so rm,

No warantee at all, but it works for me (precise).