Consider hardening SystemD service
SystemD offers some strong sandboxing capabilities out of the box that could greatly improve security with minimal changes.
Most (if not all) hardening options are safely ignored with a warning if they require a feature not supported by the host.
SystemD ships a useful tool called systemd-analyze security which displays
and “grades” the security of a service. Maybe, we could start by gradually
adding the most basic and safe features (e.g. PrivateTmp).
Security concerns aside, it also makes SysD display a smily face. :)
The examples in
systemd/{user,system}/radicle-node.serviceare really just to get people started, and not properly hardened.We don’t really have the capacity to stay up to date, but I guess it would be a good compromise to harden them once and then provide a good reference for further information, right in those files.
My approach personally is to leave updating integration with service managers (and hardening those) to the respective downstream maintainers. For example, the systemd system service distributed with NixOS is well hardened, see https://github.com/NixOS/nixpkgs/blob/99484b0aa93f17c4fda0f23da6a15d809742e9f4/nixos/modules/services/misc/radicle.nix#L66-L114
This also references
systemd-analyze security.z6MkkPvBfjP4bQmco5Dm7UGsX2ruDBieEHi8n9DVJWX5sTEz wrote:
My bad, I thought they were upstream services. But yeah, adding some comments to inform users of its referential status and some examples of simple, good practices as a best effort.
I could even try submitting a patch…