[RFC] Improve systemd service unit #477
Conversation
If the build is configured with a non-default pathname to the root key
file, for example, `--with-rootkey-file=/var/unbound/root.key`, that
path needs to be read and writable by Unbound, so add it to the list of
directories Unbound can read from and write to.
ReadWritePaths=/etc/unbound /etc/unbound
unbound[6269]: [1619522080] unbound[6269:0] fatal error: could not open autotrust file for writing, /var/unbound/root.key.6269-0-593e60: Read-only file system
Resolves: NLnetLabs#475
That’s semantically more correct than putting it in `ReadWritePaths`. It normally maps to `/run` and is cleared when the service is stopped.
This is configured when building Unbound, so use it.
|
@Maryse47, @hardfalcon, it’d be great if you shared your expertise. |
| @@ -63,8 +63,8 @@ ProtectHome=true | |||
| ProtectControlGroups=true | |||
| ProtectKernelModules=true | |||
| ProtectSystem=strict | |||
| RuntimeDirectory=unbound | |||
| ConfigurationDirectory=unbound | |||
| RuntimeDirectory=@UNBOUND_RUN_DIR@ | |||
There was a problem hiding this comment.
In unbound UNBOUND_RUN_DIR points to where config is stored (also default working/chroot directory) which is usually /etc/unbound. systemd RuntimeDirectory points to path under /run so those aren't related beside similar name.
There was a problem hiding this comment.
Unless I'm mistaken, all of these directories must be relative.
Excerpt from https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RuntimeDirectory=:
RuntimeDirectory=, StateDirectory=, CacheDirectory=, LogsDirectory=, ConfigurationDirectory=
These options take a whitespace-separated list of directory names. The specified directory names must be relative, and may not include "..".
There was a problem hiding this comment.
Right, which means it's not even possible to set it this way.
| RuntimeDirectory=unbound | ||
| ConfigurationDirectory=unbound | ||
| RuntimeDirectory=@UNBOUND_RUN_DIR@ | ||
| ConfigurationDirectory=@UNBOUND_SYSCONF_DIR@ |
There was a problem hiding this comment.
UNBOUND_SYSCONF_DIR is the upper system sysconfdir, usually /etc while ConfigurationDirectory expects specific lower dir name beneath.
| @@ -73,7 +73,7 @@ SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module mount @obsolete | |||
| RestrictNamespaces=yes | |||
| LockPersonality=yes | |||
| RestrictSUIDSGID=yes | |||
| ReadWritePaths=@UNBOUND_RUN_DIR@ @UNBOUND_CHROOT_DIR@ | |||
| ReadWritePaths=@UNBOUND_CHROOT_DIR@ @UNBOUND_ROOTKEY_FILE@ | |||
There was a problem hiding this comment.
UNBOUND_RUN_DIR should stay for reasons stated above.
As you pointed out in #475 UNBOUND_ROOTKEY_FILE won't add write access to whole dir where key is stored when it's changed from default UNBOUND_RUN_DIR/root.key. When it's not changed then it isn't needed as UNBOUND_RUN_DIR is already covered so adding UNBOUND_ROOTKEY_FILE here doesn't fix anything really.
There was a problem hiding this comment.
I'm not an expert in this field, but it appears to me that chrooting into a directory that is writable to the user you are trying to constrain is a potential security issue. Here's a StackExchange post that explains the issue better than I could:
https://unix.stackexchange.com/a/332571
This tl;dr is: If an attacker manages to exploit a vulnerability in the unbound process and run malicious code within the context of that process, (s)he could potentially gain persistence across daemon restarts by creating a specially crafted /etc and/or /lib and/or /usr within the chroot directory.
There was a problem hiding this comment.
Right, chroot is considered as weak security boundary but using it is default unbound behavior. The service doesn't make anything worse here.
There was a problem hiding this comment.
We definitely need to use TemporaryFileSystem=/:ro without ProtectSystem - I think the system would be again mounted over a TemporaryFileSystem as a read-only. I'll test this configuration and will try to come up with the solution.
No description provided.