Running unbound in a chroot: Which files need to be accessible?

Unbound
1

Hi,

I'm currently running unbound 1.8.0 on Linux (Debian) and wonder how to properly set up the chroot environment – especially which files need to be accessible from within the chroot.

1) I'm using the tls-cert-bundle option in order to forward requests to upstream servers that support DNS over TLS. The certificate bundle is outside of unbound's configuration directory and chroot directory. In a quick test, I'm able to run unbound in a chroot, without making the certificate bundle available from within the chroot. So, I'm assuming the certificate bundle is read before unbound enters the chroot and not accessed anymore afterwards. But is this always true? Will unbound at some point need access to the tls-cert-bundle from within the chroot?

2) On Debian with systemd, unbound is a service of the type "notify". A bug report suggests that the socket /run/systemd/notify should be made accessible from within the chroot[1]. Is this needed? During my little testing, it didn't seem to make a difference whether the socket was bind mounted to the chroot or not.

3) The man page mentions that /dev/random should be accessible. Since I don't run into errors when I set up the chroot without a bind mount for /dev/random, I'm wondering whether access to /dev/random is only needed in certain configurations? The same goes for /dev/log. But is this really needed regardless of whether a log file or syslog is used for logging?

4) Are there any other files/locations that should be made accessible inside the chroot in order to ensure reliable operation, aside from the configuration files and the auto-trust-anchor-file? If I look at the apparmor profile for unbound, it seems a lot more files might be accessed, but of course that might only be the case before chroot is entered.

I'd appreciate any clarification someone might give on this.

Thanks!

Kind regards,

Timo

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867187

2

Hi,

Hello Timo,

I'm currently running unbound 1.8.0 on Linux (Debian) and wonder how to properly set up the chroot environment – especially which files need to be accessible from within the chroot.

I have "dev/random" and a copy of "etc/unbound/unbound.conf"

1) I'm using the tls-cert-bundle option in order to forward requests to upstream servers that support DNS over TLS. The certificate bundle is outside of unbound's configuration directory and chroot directory. In a quick test, I'm able to run unbound in a chroot, without making the certificate bundle available from within the chroot. So, I'm assuming the certificate bundle is read before unbound enters the chroot and not accessed anymore afterwards. But is this always true? Will unbound at some point need access to the tls-cert-bundle from within the chroot?

try something like "unbound-control reload" or "killall -HUP unbound".
See if the PID is still the same and check if something break.

To make remote control work, I set
remote-control:
        control-enable: yes
        control-interface: /run/unbound-control.socket
        control-use-cert: no

This socket is setup as root in a directory (/run) only writeable by root. Later unbound change the permissions to 0660, user unbound, group unbound (at least here)
There is no need to access that socket from inside chroot.

2) On Debian with systemd, unbound is a service of the type "notify". A bug report suggests that the socket /run/systemd/notify should be made accessible from within the chroot[1]. Is this needed? During my little testing, it didn't seem to make a difference whether the socket was bind mounted to the chroot or not.

unbound works fine without systemd, too :slight_smile:

3) The man page mentions that /dev/random should be accessible. Since I don't run into errors when I set up the chroot without a bind mount for /dev/random, I'm wondering whether access to /dev/random is only needed in certain configurations? The same goes for /dev/log. But is this really needed regardless of whether a log file or syslog is used for logging?

I don't use bind mounts but simply run "mknod --mode 0666 $(CHROOT)/dev/random c 1 8"

I've no syslog at all but logging to STDOUT

4) Are there any other files/locations that should be made accessible inside the chroot in order to ensure reliable operation, aside from the configuration files and the auto-trust-anchor-file? If I look at the apparmor profile for unbound, it seems a lot more files might be accessed, but of course that might only be the case before chroot is entered.

If you configure auto-trust-anchor-file, these file are also required inside chroot.

Normally unbound.conf define a directory statement with a value "/etc/unbound/" as default.
That way you may use relative pathnames for auto-trust-anchor-file:
auto-trust-anchor-file: trust/root-rfc5011.anchor

without chroot (chroot: "") that refer /etc/unbound/trust/root-rfc5011.anchor
with chroot (chroot: "/chroot/unbound/") the same entry refer "/chroot/unbound/etc/unbound/trust/root-rfc5011.anchor

same for root-hints which I normally don't use: A recent unbound come with recent root-hint data ...

Andreas

3

Hi Alexander,

thanks for your reply. Please see my comments below.

Hi,

Hello Timo,

I'm currently running unbound 1.8.0 on Linux (Debian) and wonder how to
properly set up the chroot environment ? especially which files need to be
accessible from within the chroot.

I have "dev/random" and a copy of "etc/unbound/unbound.conf"

1) I'm using the tls-cert-bundle option in order to forward requests to
upstream servers that support DNS over TLS. The certificate bundle is outside
of unbound's configuration directory and chroot directory. In a quick test,
I'm able to run unbound in a chroot, without making the certificate bundle
available from within the chroot. So, I'm assuming the certificate bundle is
read before unbound enters the chroot and not accessed anymore afterwards. But
is this always true? Will unbound at some point need access to the
tls-cert-bundle from within the chroot?

try something like "unbound-control reload" or "killall -HUP unbound".
See if the PID is still the same and check if something break.

I ran some more tests as suggested and basically nothing breaks and the
PID stays the same. I have not included the cert-bundle in my chroot
and it continues to run fine even after a reload. More deails on
/dev/log and /run/systemd/notify below.

If someone could confirm that the cert-bundle is really not relaoded
even after a longer period of time, that would be nice. But I guess I
will figure it out at some point either way when I deploy this setup :wink:

To make remote control work, I set

<snip>
Debian has the control interface preconfigured by default, so I didn't
need to change anything here.

2) On Debian with systemd, unbound is a service of the type "notify". A bug
report suggests that the socket /run/systemd/notify should be made accessible
from within the chroot[1]. Is this needed? During my little testing, it didn't
seem to make a difference whether the socket was bind mounted to the chroot or
not.

unbound works fine without systemd, too :slight_smile:

Sure. But it still seems like a reasonable question for any systemd
user. During my further testing, I figured out the following:
While unbound will run just fine, without /run/systemd/notify being
accessible inside the chroot, it's better to expose the socket to the
chroot. Otherwise systemd will get "confused" about the state of
unbound, such as indicating that unbound is still starting or reloading
whereas it's up and running fine (or failed). I guess catching failures
is most relevant here. With the socket available inside the chroot,
systemd will show status changes instantly. So, unbound will make use
of it if it's there.

3) The man page mentions that /dev/random should be accessible. Since I don't
run into errors when I set up the chroot without a bind mount for /dev/random,
I'm wondering whether access to /dev/random is only needed in certain
configurations? The same goes for /dev/log. But is this really needed
regardless of whether a log file or syslog is used for logging?

I don't use bind mounts but simply run "mknod --mode 0666 $(CHROOT)/dev/random
c 1 8"

I've no syslog at all but logging to STDOUT

I use syslog. But it seems /dev/log is not required inside the chroot.
It continues to log just fine to syslog even after a reload. I even
tested with stdout and stderr redirected to /dev/null to make sure it
logs via syslog. I found two old changelog entries indicating that
/dev/log is opened before the chroot is entered without the need to
reload it afterwards [1][2]. If someone could confirm that is still
true today, I'd suggest dropping the mention of /dev/log in the man
page.

[1] unbound-1.5.1-1.el6 | Build Info | CentOS Community Build Service
[2] https://www.nlnetlabs.nl/svn/unbound/trunk/doc/Changelog
(search for "dev/log" inside these changelogs)

4) Are there any other files/locations that should be made accessible inside
the chroot in order to ensure reliable operation, aside from the configuration
files and the auto-trust-anchor-file? If I look at the apparmor profile for
unbound, it seems a lot more files might be accessed, but of course that might
only be the case before chroot is entered.

If you configure auto-trust-anchor-file, these file are also required inside
chroot.

I already had that included, thanks.

<snip>

Thanks and regards,

Timo