Bug#1010271: unbound-control: Please use unix socket as default control-interface

[ceddral]

Package: unbound
Version: 1.15.0-4
Severity: normal
X-Debbugs-Cc: debi...@ceddral.org

Dear Maintainer,

unbound package upgrade introduced a default config to enable remote-control
via tcp socket. Please change the default config to use a unix socket and avoid
the attack surface of a tcp socket with ssl authentication. e.g.:
remote-control:
control-enable: yes
control-interface: /var/lib/unbound/control.socket

Cheers
ceddral


-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unbound depends on:
ii adduser 3.121
ii init-system-helpers 1.62
ii libc6 2.33-7
ii libevent-2.1-7 2.1.12-stable-5
ii libnghttp2-14 1.43.0-1
ii libprotobuf-c1 1.3.3-1+b2
ii libpython3.10 3.10.4-3
ii libssl1.1 1.1.1n-1
ii libsystemd0 250.4-1
ii lsb-base 11.1.0

Versions of packages unbound recommends:
ii dns-root-data 2021011101
ii openssl 1.1.1n-1

Versions of packages unbound suggests:
pn apparmor <none>

-- Configuration Files:
/etc/unbound/unbound.conf changed [not included]

-- no debconf information

[Michael Tokarev]

Control: severity -1 wishlist
Control: tag -1 confirmed

27.04.2022 16:48, ceddral wrote:
> Package: unbound
> Version: 1.15.0-4
> Severity: normal
> X-Debbugs-Cc: debi...@ceddral.org
>
> Dear Maintainer,
>
> unbound package upgrade introduced a default config to enable remote-control
> via tcp socket.

Can you tell please which version did you upgrade from?
Please note that before, unbound in Debian had a patch
to secretly enable remote-control socket which by default
is tcp. In this release I just made it explicit instead of
doing it secretly.

> Please change the default config to use a unix socket and avoid
> the attack surface of a tcp socket with ssl authentication. e.g.:
> remote-control:
> control-enable: yes
> control-interface: /var/lib/unbound/control.socket

Actually it was my thought to enable control socket (I'm not
sure /var/lib/unbound is a good place for it, /run sounds
better but I need to check if it works when unbound is
chrooted.

unbound.postinst generates the ssl certificates for quite a
long time, these probably should go away too. And we'd better
check if unbound-control-setup script does the right thing.

So I thought I'd keep it the way it were for a long time.

And the most important is that it is the upstream default
for control socket. Maybe we should specify it in the
config file the way I did it in this release.

Thanks,

/mjt

[ceddral]

> Can you tell please which version did you upgrade from?
> Please note that before, unbound in Debian had a patch
> to secretly enable remote-control socket which by default
> is tcp. In this release I just made it explicit instead of
> doing it secretly.

Right you are, the socket was open before. I don't know which
unbound version I had before. The tcp socket only came to my
attention now being explicit in the config. Now that I'm aware
I do believe a unix socket would be the more sensible default.

> Actually it was my thought to enable control socket (I'm not
> sure /var/lib/unbound is a good place for it, /run sounds
> better but I need to check if it works when unbound is
> chrooted.

Tested it, as far as i can tell it works for me with
chroot: "/var/lib/unbound"
and
control-interface: "/run/unbound-control.socket"
(and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify
in the systemd service file)

My test was `unbound-control stats` says something.

Cheers
ceddral

[Michael Tokarev]

27.04.2022 19:38, ceddral wrote:
..

> Tested it, as far as i can tell it works for me with
> chroot: "/var/lib/unbound"
> and
> control-interface: "/run/unbound-control.socket"

Thank you for confirming this. I too did the similar test locally,
you made me curious.

> (and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify
> in the systemd service file)

This is not necessary anymore, but I guess it is nicer this way.
The difference is that the setup script (/usr/libexec/unbound-helper)
does the mount already but this mount is visible for all other
processes. While .service way makes it private to this process
(with its own namespace).

This whole thing isn't actually necessary, it is only needed to
notify systemd when unbound is finished initializing. It might
be easier in cases like this if systemd passed an open file
descriptor to the process where it can write to, so there's
no need to open a (named) socket. I wonder if there's a way
to avoid this bind-mount...

> My test was `unbound-control stats` says something.

Yeah. I think it's a good idea to switch to unix socket.

Please also note that linux actually honors the file permissions
for the socket files, - unlike on some other systems.

And there's one more thing: unbound chowns the socket to
unbound user. I don't know why it is doing this, - ditto
for the pid file.

FWIW, I tend to chroot it to /etc/unbound, - which needs
bind-mounting of /var/lib/unbound to /etc/unbound/ somewhere,
but reduces the need for copying /etc/unbound to /var/lib.
This copying is bad: besides it makes reloading unbound more
difficult, it is also very security-sensitive, I highly
doubt the copy procedure is "secure enough". Creating files
as root in a unprivileged /var/lib/unbound is problematic.
See how I did root.key handling in unbound-helper.

Thank you!

/mjt

[Michael Tokarev]

27.04.2022 19:38, ceddral wrote:

...

> attention now being explicit in the config. Now that I'm aware
> I do believe a unix socket would be the more sensible default.

This variant (the unix socket) weren't always available.
It was implemented in version 1.5.2, and I wasn't aware
of this until 1.15.

/mjt