bind chroot not allowed

[Aaron Bennett]

Binary package hint: apparmor

I have a custom apparmor profile for /usr/sbin/named which allows chroot. It's attached. With that profile, bind9 fails as follows:

named: chroot(): Permission denied

the reason I suspect an apparmor bug is that if I switch to complain mode and then directly back to enforce mode, it works as follows:

root@newnyx:~# complain /usr/sbin/named ; enforce /usr/sbin/named ; service bind9 start
Setting /usr/sbin/named to complain mode.
Setting /usr/sbin/named to enforce mode.
 * Starting domain name service... bind9 [ OK ]
root@newnyx:~#

however, any time I restart apparmor it goes right back to not allowing the chroot.

I have attached both my apparmor conf for named and a strace -f output.

[Aaron Bennett (abennett-clarku)]

strace -f output...

[Serge Hallyn (serge-hallyn)]

Can you see if there is anything in /var/log/kern.log?

[Aaron Bennett (abennett-clarku)]

Yeah I checked before, this is all it dumps:

Oct 22 15:23:09 newnyx kernel: [20117.151219] type=1503 audit(1287775389.320:44): operation="capable" pid=28057 parent=28042 profile="/usr/sbin/named" name="dac_read_search"

If it's set to 'complain' it doesn't dump anything.

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf
> Of Serge Hallyn
> Sent: Friday, October 22, 2010 3:11 PM
> To: Aaron Bennett
> Subject: [Bug 665264] Re: bind chroot not allowed
>
> Can you see if there is anything in /var/log/kern.log?
>
> ** Tags added: apparmor
>
> --
> bind chroot not allowed
> https://bugs.launchpad.net/bugs/665264
> You received this bug notification because you are a direct subscriber of the
> bug.
>
> Status in “apparmor” package in Ubuntu: New
>
> Bug description:
> Binary package hint: apparmor
>
> I have a custom apparmor profile for /usr/sbin/named which allows chroot.
> It's attached. With that profile, bind9 fails as follows:
>
> named: chroot(): Permission denied
>
> the reason I suspect an apparmor bug is that if I switch to complain mode and
> then directly back to enforce mode, it works as follows:
>
> root@newnyx:~# complain /usr/sbin/named ; enforce /usr/sbin/named ;
> service bind9 start Setting /usr/sbin/named to complain mode.
> Setting /usr/sbin/named to enforce mode.
> * Starting domain name service... bind9
> [ OK ]
> root@newnyx:~#
>
> however, any time I restart apparmor it goes right back to not allowing the
> chroot.
>
> I have attached both my apparmor conf for named and a strace -f output.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/665264/+subs
> cribe

[Aaron Bennett (abennett-clarku)]

all you get in kern.log:

Oct 22 15:23:09 newnyx kernel: [20117.151219] type=1503 audit(1287775389.320:44): operation="capable" pid=28057 parent=28042 profile="/usr/sbin/named" name="dac_read_search"

if it's in complain mode you get nothing in kern.log fwiw.

[Serge Hallyn (serge-hallyn)]

Ah, ok, so please add

  capability dac_read_search,

to the profile. Does that then suffice?

[Aaron Bennett (abennett-clarku)]

It's already there, towards the bottom.

[Jamie Strandboge (jdstrand)]

Aaron,

You'll need to reload the profile into the kernel with:
$ sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.named

[Aaron Bennett (abennett-clarku)]

Jamie, I did that as you suggested. While it does allow bind9 to start after it's run, rebooting the computer or restarting apparmor makes it stop working as below:

root@newnyx:~# apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.named
root@newnyx:~# service bind9 start
 * Starting domain name service... bind9 [ OK ]
root@newnyx:~# service bind9 stop
 * Stopping domain name service... bind9 [ OK ]
root@newnyx:~# service apparmor restart
 * Reloading AppArmor profiles [ OK ]
root@newnyx:~# service bind9 start
 * Starting domain name service... bind9 named: chroot(): Permission denied
                                                                                                                                  [fail]

[Jamie Strandboge (jdstrand)]

@Aaron,

I'm confused. If you added 'capability dac_read_search,' and then ran this:
$ sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.named

Then the profile cache should be updated for the next reboot. Can you give detailed steps to reproduce the problem on reboot or restart of AppArmor.

[Aaron Bennett (abennett-clarku)]

@Jamie --

That's exactly what I did, and why it's so strange.

Reproducer:

1. Install bind and make a chrooted bind in /var/bind/chroot
2. Put the attached usr.sbin.named in /etc/apparmor.d over the existing usr.sbin.named
3. Run commands in step #9.

[Jamie Strandboge (jdstrand)]

I understand why this isn't working on reboot-- I misread your comment. When you do this:
1. aa-complain
2. start bind
3. aa-enforce

bind is still running unconfined (you can see this with 'aa-status'). If you were to stop then start bind, the enforcing profile would be in effect, and therefore bind won't start. This is also what is happening on reboot.

The question then becomes how do you adjust the enforcing profile to work correctly within your environment. This doesn't see like a bug, but rather a configuration problem. Let's start over:

1. after a reboot (and therefore the failed bind9 start), please attach the output of:
$ sudo apparmor_parser -p /etc/apparmor.d/usr.sbin.named

2. please attach your kern.log

[Jamie Strandboge (jdstrand)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to 'New'. Thanks again!