[RFC] Hardening tinc systemd service

[Graham Cobb]

On 06/04/2021 20:09, Oleksandr Natalenko wrote:
> (resending after ml approval)
> 
> Hello.
> 
> I'm currently working on hardening the tinc's systemd service file.
> 
> Here are the principles I'm following:
> 
> 1. employing all the hardening knobs possible as per
>    `systemd-analyze security tinc@` output for the latest systemd stable
>    release available
> 2. running tincd on behalf of dynamic non-root user so that no static
>    user creation is needed; a user per network is used
> 3. making the current host keys, both public and private, a part of
>    state, not a configuration; in systemd's terms it means that the keys
>    of the current host should move under /var/lib, while /etc stays
>    immutable

Personally, I'm not keen on that. To me, the keys are config data. Where
they are generated is completely separate from where they are used. It
depends on which direction and/or tools are being used for moving them
around. For example, sometimes I may generate the keys for a client on
the central router (or even a third system) and copy them from there to
the client. Because of firewalls and/or NAT, clients often do not have
SSH access into the router except over tinc, but SSH access from the
central router out to the client may be easier to set up in some
circumstances.

I would also like to be sure the node's private key is deleted by just
deleting /etc/tinc, not go looking for it somewhere in /var/lib.

And on some systems I backup /etc but do not back up /var/lib. Losing
tinc just because a file has been corrupted would be a pain to recover.

Of course, I realise I can do everything I need to with your approach,
but it just makes my life harder and breaks my conceptual model of where
the configuration data lives.

Just my personal view.