via security@suse.de:

I believe to have found a configuration issue in the Unbound package.
Or, depending on how you look at it, in the Unbound server itself.

1.  Before starting the Unbound server, systemd routinely runs unbound-anchor.

    From 'systemctl cat unbound':

        ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a
/var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem

    As you can see this process is run as user unbound.


2.  The Unbound server writes a pid file before dropping privileges, i.e. as
root. It then chown's the file in a second step.

    'grep username /etc/unbound/unbound.conf':

        username: "unbound"

    And from the Unbound source:

       
https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f920366b/daemon/unbound.c#L506

    As you can see in the source, Unbound doesn't check if there is already a
symbolic link in place of the
    pid file.


3.  openSUSE configures Unbound to create the pid file in a directory owned by
the unbound user.

    'grep pidfile /etc/unbound/unbound.conf':

        pidfile: "/var/run/unbound/unbound.pid"

    'cat /usr/lib/tmpfiles.d/unbound.conf':

        D /run/unbound 0755 unbound unbound -


4.  unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool.

    But if it is compromised, and as it has write permission in the pid file
directory and reliably runs before the server,
    an attacker could easily gain full root privileges by just creating a
symbolic link /run/unbound/unbound.pid.


5.  IMHO this would be best fixed in openSUSE by creating a root owned
/run/unbound directory,
    or changing the pid file path to /run/unbound.pid or something like that.

    I think this would have the added advantage that openSUSE could ship and
maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu:

       
https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/usr.sbin.unbound

    With the current openSUSE setup there is the problem that if AppArmor
filters CAP_DAC_OVERRIDE, Unbound has no permission
    to create a pid file in /run/unbound anymore.


If you have questions please don't hesitate to contact me.
Thanks for taking a look.

Kind regards,
Detlef