AppArmor breaks the default Unbound installation in a live session

[Tore Anderson]

Immediately after installing Unbound, it starts up normally. However, if you try to restart it afterwards (without changing anything), it fails with the following error message:

Aug 25 10:41:26 ubuntu unbound[6650]: /etc/unbound/unbound.conf:10: error: cannot open include file '/etc/unbound/unbound.conf.d/*.conf': No such file or directory
Aug 25 10:41:26 ubuntu unbound[6650]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file
Aug 25 10:41:26 ubuntu unbound[6650]: [1566729686] unbound[6650:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf

There *are* files matching the above glob pattern, however:

root@ubuntu:~# echo /etc/unbound/unbound.conf.d/*.conf
/etc/unbound/unbound.conf.d/qname-minimisation.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf

unbound-checkconf, on the other hand, determines the configuration to be fine:

root@ubuntu:~# unbound-checkconf
unbound-checkconf: no errors in /etc/unbound/unbound.conf

In the kernel log I can see that AppArmor is the probable culprit:

Aug 25 10:41:26 ubuntu kernel: audit: type=1400 audit(1566729686.377:239): apparmor="DENIED" operation="open" profile="/usr/sbin/unbound" name="/upper/etc/unbound/unbound.conf.d/" pid=6650 comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Steps to reproduce:

1. Download ubuntu-19.04-desktop-amd64.iso from https://ubuntu.com/download/desktop
2. Boot the downloaded ISO file in a virtual machine
3. Start gnome-terminal
4. sudo -i
5. apt-add-repository universe
6. apt -y install unbound
7. systemctl status unbound # verify that it is runnning
8. systemctl restart unbound
9. systemctl status unbound # verify that it failed to start
10. journalctl -kn1 # display AppArmor error message

[Simon Déziel (sdeziel)]

The "/upper" dir in the apparmor denial message makes me suspect that unbound was installed in the livecd environment. @Tore, is that what you tried to do? Setting to incomplete while waiting for a confirmation on the livecd env.

[Tore Anderson (toreanderson)]

Correct, as mentioned under «Steps to reproduce» I did my testing using live media in a virtual machine.

Tore

[Simon Déziel (sdeziel)]

Thanks. The live environment being a special one, I'm not sure how to deal with this at the Apparmor level. Maybe an alias rule ("alias /upper/ -> /,") would do? Or possibly skip loading the Apparmor profile when inside a live session?

[Tore Anderson (toreanderson)]

I don't know anything about AppArmor, so I am afraid I can't help you with that.

I was just researching DNSSEC validators for a blog post I'm working on, testing them on both Fedora and Ubuntu (using a live VM). Since Unbound didn't seem to work (unless I did 'aa-complain /usr/sbin/unbound') I thought I'd submit a bug. I didn't realise the problem was caused by my use of the live media, as I was under the impression that the live media was expected to work the same as a regular installation.

In any case, I'll be able to finish my blog post so it's not important for me that this issue is fixed.

Tore

[Simon Déziel (sdeziel)]

That's a valid bug so thanks for reporting! I'll try to do a follow-up with the relevant folks @Ubuntu regarding possible ways to improve the experience in the live session. Good luck with your research on DNSSEC!

[Simon Déziel (sdeziel)]

Would you mind testing the alias rule I suggested in comment #3? If it works, it would in theory fix not only Unbound but every applications shipping with an Apparmor profile.

[Tore Anderson (toreanderson)]

Sure, I can test if you tell me how, ideally spoon-fed. Like I said, I have no experience with AppArmor so I don't know how to install alias rules.

By the way, I finished the my blog post, of the six DNSSEC validators I tested it was only Unbound that didn't work in the live environment (but of course it might be that none of the others are using AppArmor): https://www.redpill-linpro.com/techblog/2019/08/27/evaluating-local-dnssec-validators.html

Tore

[Simon Déziel (sdeziel)]

As root:

 echo 'alias /upper/ -> /,' >> /etc/apparmor.d/tunables/alias
 rm -f /etc/apparmor.d/force-complain/usr.sbin.unbound
 apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.unbound
 service unbound restart

Then you should hopefully see no more Apparmor denials.

[Tore Anderson (toreanderson)]

That does not work, same error message when attempting to restart unbound.

The apparmor_parser command results in the following being logged to the system journal:

aug. 28 16:08:02 ubuntu audit[6536]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/unbound" pid=6536 comm="apparmor_parser"
aug. 28 16:08:02 ubuntu kernel: audit: type=1400 audit(1567008482.755:240): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/unbound" pid=6536 comm="apparmor_parser"

Also, the /etc/apparmor.d/force-complain/usr.sbin.unbound does not exist, so the rm -f command is a no-op.

Tore

[Simon Déziel (sdeziel)]

I use the alias feature in reverse (doh!). That one did the trick:

  # /etc/apparmor.d/tunables/alias
  alias / -> /upper/,

[Christian Ehrhardt  (paelzer)]

That would be a change in apparmor to generally help the live system, and much less an unbound specific issue.
Therefore I added a task for apparmor for the people triaging/fixing that to take a look.

[Tore Anderson (toreanderson)]

I can confirm that the following commands fixes the problem so Ubound can start again:

 echo 'alias / -> /upper/,' >> /etc/apparmor.d/tunables/alias
 apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.unbound

I noticed that when it starts, another AppArmor-related error message is logged:

[ 257.707923] audit: type=1107 audit(1567174888.349:247): pid=976 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers" mask="send" name="org.freedesktop.systemd1" pid=6735 label="/usr/sbin/unbound" peer_pid=1 peer_label="unconfined"
                exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?'

However, it does not appear to cause any problems as far as I could tell.

Tore

[Simon Déziel (sdeziel)]

Yeah, this GetDynamicUsers denial is probably unrelated and should/will be addressed in another bug. Thanks for double checking the alias trick!