> On 8. Nov 2019, at 12:43, Stuart Henderson <s...@spacehopper.org> wrote: > On 2019/11/08 11:46, Frederic Cambus wrote: >> >> Here is a diff to update gdnsd to 2.4.3. This fixes CVE-2019-13952. >> >> While there, switch MASTER_SITES to HTTPS. > > OK. > > I looked at updating to 3.x earlier but then I read "The TL;DR here is > that gdnsd doesn't manage its own OS security or privileges anymore. It > just runs and assumes the environment was already secured by the init > system or script, and assumes it can bind port 53" and put it in the > "too-hard basket”.
Actually, I found some time to look into this and I got recent version 3.x compiling and working with a few patches. But the removed privileges are indeed an issue… How are we supposed to handle such ports in general? I guess with the raise of systemd there will be more such types of “daemons" coming. For the user environment, I believe rc script can already start things as daemon_user=“_gdnsd”. But since we have no authbind, CAP_NET_BIND_SERVICE (Linux), or mac_portacl (FreeBSD) the actual port binding will be a problem. What are our options here? Maybe just suggest in pkg README to add a “transparent" PF rule to redirect port 53 -> 5353 (with an example)? Use some other kind of user-space tcp proxy in front, e.g. net/balance? Any other ideas? Thanks, Regards, Joerg ps: the author seems upset about his own choices here and even apologises, see (last paragraph): https://github.com/gdnsd/gdnsd/blob/master/VERSION3.md
