systemd: is there interest in providing a static file with a fine-tuned systemd configuration?

[cobratbq]

I've started using dnscrypt-proxy through the package provided as part of Debian bullseye. It works quite well, and that includes the use of systemd sockets. I noticed that dnscrypt-proxy already supports systemd-notify signaling to update on the status of the service.

Would there be interest in adding a fine-tuned configuration for systemd for reference that includes:

• systemd sockets (to open up more options for hardening)
• let systemd sockets bind to loopback-device by default to make it more resilient to interface changes if you only serve the localhost anyways
• systemd service of type Type=notify that leverages the notify capabilities, allowing systemd to watch the process
• hardened configuration, including most ProtectX options that are applicable
• (possibly more ... I haven't fully investigated)

[dmdmdm]

Hi, I made a systemd override file for the unit. It works for me... https://github.com/dmdmdm/systemd_overrides/blob/main/system/dnscrypt-proxy.service.d/override.conf

[cobratbq]

right, this is indeed what I was thinking of. I will definitely compare. You have significantly more protective options active.
Two remarks I have from quickly reading throught the config, in case you're interested:

• Type=notify is possible. Systemd will monitor the start-up process. However, it will delay the start-up more if no internet access is available yet. You probably want to check if you are happy with its behavior. (Might be nicer if combined with systemd sockets.)
• Do you use a systemd socket? (.socket) If you do, you can additionally bind the socket to the loopback-device, such that dnscrypt-proxy reachability, locally on port 53/UDP, is not affected when you connect/disconnect your network interfaces. (For me, in .socket unit: BindToDevice=lo.)

[dmdmdm]

Thanks for the info. I don't mind haven't it run all the time - since I expect there will be lots of queries.

[cobratbq]

I am currently testing with https://gist.github.com/cobratbq/fbb3119f2ae641f42a9711d6b6fc42bf#file-dnscrypt-proxy-service-hardened
→ Overall exposure level for dnscrypt-proxy.service: 1.1 OK (systemd 247 (247.3-7))

Note that this requires (probably) the use of systemd-sockets to work.

@dmdmdm the way it is set up in Debian -- which I used as a basis, dnscrypt-proxy is still running all the time. The systemd-sockets make it possible to further restrict access. In this set-up it allows easy binding to loopback-device and the service itself now only requires /dev/stdin.

Note: apparently you can get detailed info when running systemd-analyze security dnscrypt-proxy.service

[cobratbq]

@jedisct1 just an FYI: https://gist.github.com/cobratbq/d3b778da36a063f03a932ccc26e74ab1#file-systemd-analyze-dnscrypt-proxy-log shows how much dnscrypt-proxy can be restricted when run from systemd with systemd-sockets. I am working with this and so far everything is fine. If you are interested, I can upstream the systemd config files as (alternative) example files.