Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start

505 views
Skip to first unread message

Michael Tokarev

unread,
May 3, 2022, 7:50:04 AM5/3/22
to
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

There are 2 issues there: the wrong apparmor profile and the behavour
of unbound which makes this error to be fatal.

/mjt

Michael Tokarev

unread,
May 3, 2022, 10:30:03 AM5/3/22
to
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

Simon Deziel

unread,
May 3, 2022, 10:30:03 AM5/3/22
to
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:

# cat /etc/unbound/unbound.conf.d/chroot.conf
server:
chroot: "/var/lib/unbound"


I just tested the above and it seems to work.

HTH,
Simon

Simon Deziel

unread,
May 3, 2022, 10:40:04 AM5/3/22
to
Could a bind mount of the control socket make it work? Similar to
systemd's notify socket.

> Copying configs is bad, I think.

Well, the way unbound chroots feels awkward to me. I don't understand
why stuff needs to be present in the chroot. I maybe naively think that
unbound-control could have supplied fresh configs to the running
chroot'ed daemon without having to move files/sockets/pid/etc around.


>> # 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.

If you'd like to have your bind-mount setup to work, I'm happy to add
the missing apparmor bits to
https://salsa.debian.org/dns-team/unbound/-/merge_requests/19

Thanks,
Simon
0 new messages