Harden systemd service for Nix module #919

Thank you for your contribution!

tbh I'm not fully understanding what all those option mean, but afaict this is roughly same to what bluesky-pds is using except these chunks. So I guess it's fine to blindly merge? cc @anirudh.fi

• https://tangled.org/tangled.org/core/pulls/919/round/0#nix%2fmodules%2fknot.nix-N286
• https://tangled.org/tangled.org/core/pulls/919/round/0#nix%2fmodules%2fknot.nix-N308
• https://tangled.org/tangled.org/core/pulls/919/round/0#nix%2fmodules%2fknot.nix-N318

@hauleth.dev can we have at least CAP_NET_BIND_SERVICE to CapabilityBoundingSet? Users should be able to set knot port directly to 80/443.

i'd want to test some of these more closely:

• we depend on the git binary in certain places, will this config prevent shelling out to such a process depending on ownership of the git binary? (and if so, maybe that is fine?)
• we write, setup and execute hooks as shell scripts, we should verify that it continues to execute as expected
• we should verify that the network restriction configs continue to work with wss consumption and emitting

side note @hauleth.dev, is SystelCallArchitecture a typo for SystemCallArchitecture, trying to find the docs for this.

@boltless.me, I think that if someone wants to bind directly to 80/443 instead of using some reverse proxy they should set that capability on their own, by default that should not be set there in my opinion.

Syscall filtering should not affect the service, as it is "default set" that allows most of the sys calls except for stuff like adjusting system clock or (un)mounting filesystems.

About listening on restricted ports, I think it would be better to make knot binary to be able to utilise systemd sockets injection via LISTEN_FDS, which would allow knot to listen on any port or even to be launched on-demand instead of immediately.

@oppi.li, this will allow shelling out to Git binary as long as it is in /nix/store, however I am not sure how that will work with shell scripts in repositories. I haven't tested that behaviour.

WSS should work just fine, because WSS is L5-7 protocol and systemd hardening cannot do anything about it. It restricts access only to L3 protocols (not even L4) which is Internet Protocols and UNIX sockets. In theory we can restrict also interfaces that the service is allowed to listen on, but on the first iteration I wanted to be as little intrusive as possible.

thanks for that! will give this a test and post findings, if any, here.