03.05.2022 17:08, Simon Deziel wrote:
On 2022-05-03 07:44, Michael Tokarev wrote:
Package: unbound
Version: 1.15.0-8
Severity: normal
When enabling apparmor, unbound fails to start. From the dmesg:
audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \
operation="mknod" profile="/usr/sbin/unbound" \
name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \
pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \
fsuid=930 ouid=930
from the unbound log:
unbound: [68281:0] fatal error: could not open autotrust file for writing, \
/var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied
I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed
with the following in mind IIRC:
Oh. Yes, you're right, I haven't noticed the difference here between
unbound message and kernel message.
This explains why I can't fix it by adding stuff for /var/lib/unbound
to aparmor.d/.
Yes, I chroot it to /etc/unbound, with /var/lib/unbound bind-mounted
to /etc/unbound/var/... - the way it was supposed to work by upstream,
apparently.
The problem with chrooting it to /var/lib/unbound is the copy of all
the configuration which must not be done by root into nonroot-owned
untrusted directory, and because you lose unbound-control reload.
Copying configs is bad, I think.
# cat /etc/unbound/unbound.conf.d/chroot.conf
server:
chroot: "/var/lib/unbound"
I just tested the above and it seems to work.
Yes, this one works (with the above comment/restriction).
And yes, adding /etc/unbound/var/lib/unbound/* stuff to
apparmor profile seems to be working as well, - something
which I missed initially, - that's why I filed this bugreport
instead of fixing it right away, - b/c I weren't able to figure
out why it doesn't work after my attempts to fix the profile.
HTH,
Definitely, thank you Simon!
/mjt
