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