[RFC] Hardening tinc systemd service

[Oleksandr Natalenko]

Hello.

On Tue, Apr 06, 2021 at 10:28:17PM +0100, Graham Cobb wrote:
> 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.

Just to reflect on this quickly: I do not suggest amending defaults.
Things may and probably should what they are by default, but there
should be new configuration options to amend hard-coded paths.

This is really all I ask about. So you should be safe :).

Thanks for your opinion!

-- 
  Oleksandr Natalenko (post-factum)