Hardened systemd unit files

[savyajha]

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request includes a changelog file. The entry should:
  • Be a short description of your change which makes sense to users. "Fixed a bug that prevented receiving messages from other servers." instead of "Moved X method from EventStore to EventWorkerStore.".
  • Use markdown where necessary, mostly for code blocks.
  • End with either a period (.) or an exclamation mark (!).
  • Start with a capital letter.
• Pull request includes a sign off
• Code style is correct (run the linters)

Signed-off-by: Savyasachee Jha [email protected]

[richvdh]

I'm unconvinced we should do this. It looks super-scary, and I've never seen any other systemd units to all this stuff. This is supposed to be a simple example for people getting synapse set up for the first time!

It might be more appropriate in a separate contrib directory or something.

[anoadragon453]

@richvdh After going through each option in systemd's manpages, they all make sense and I think the comments presented here help explain what each option is doing. That being said, you have a point that the systemd services we ship out of the box should probably be simple, so one can quickly read and edit it.

Perhaps moving these to contrib or elsewhere and hyperlinking to them as "hardened" configs from the default service files is the best way to go about it?

[richvdh]

Perhaps moving these to contrib or elsewhere and hyperlinking to them as "hardened" configs from the default service files is the best way to go about it?

yup, sounds good.

[callahad]

@richvdh Is there a path to including at least some of these directly? Systemd sandboxing feels like a really great way to add defense in depth. Perhaps just targeting debian/matrix-synapse.service and leaving the docs/systemd-with-workers/... files more bare?

[richvdh]

I don't object to it going into the unit file in the debian package (though I would question why debian doesn't do this for all services in packages in its repo, if it's such a great idea).

[richvdh]

Also: I'm not keen on us having multiple copies of this stuff that we have to remember to maintain; we are literally bound to forget to update at least one copy when there are changes. Can we do something like move the config options out to a .conf file, which is then copied into the debian package? Systemd has some nice support for sharing config files between similarly-named units.

[savyajha]

@richvdh It's not completely uncommon. I got the idea from looking at the service files of postgres and unbound as shipped by Arch Linux and upstream respectively. I think there was the principle of maintaining equivalence between unit files and traditional sysv scripts in Debian till recently which might have been a reason for them to not do this.

Regardless, do let me know what to do. Should I keep the Debian changes? Should I remove the ones in doc/ or make separate files with the -hardened suffix?

[anoadragon453]

systemd does have support for adding options to a /etc/systemd/system/your-project.d/override.conf file, which would then override options set in your-project.service. I don't know if it's good practice to bundle that file with your package (it's intended for overriding whatever options come from your distro's package) but we could:

• Include an override-hardened.conf file in the repo which users can copy to /etc/systemd/system/matrix-synapse.d/override.conf and packagers can use if they want increased security.
• Append the contents of override-hardened.conf to the service file when building the debian packages for security by default.

[savyajha]

@anoadragon453 Typically it's considered bad practice for packagers to put files in /etc/systemd/system/<service-name>.service.d/, iirc, that location is meant for end-users.

I have no issues separating the file out into an override-hardened.conf (put in contrib, I suppose?). However, given I'm not a programmer and further have no experience packaging for Debian, I would hope that appending the hardened config to the Debian service file during package-building could be done by someone else.

[richvdh]

@anoadragon453 Typically it's considered bad practice for packagers to put files in /etc/systemd/system/.service.d/, iirc, that location is meant for end-users.

Indeed. /lib/systemd/system/<unit>.d exists for packagers.

[savyajha]

I've made the changes as requested. Does this work? If it's acceptable, hopefully someone can put the file from contrib as desired into the Debian package.

[anoadragon453]

Apologies for the delay in getting back to this. I've got a few suggestions below, but overall think this looks pretty solid!

[savyajha]

My turn to apologise for the delay: the situation with covid is frankly somewhat alarming in my city. I've made the requisite changes and I hope it looks good. :)

[anoadragon453]

No worries - people's safety should always comes first. I do wish you and your family well in that regard 🙂

These changes look good to me, thank you so much!

files now live in contrib

[schildbach]

I wonder how this sandboxing solution compares to running Synapse in Docker?

[ruscur]

FYI the synapse package in Arch Linux is now enabling this by default in /usr/lib/systemd/system/synapse.service.d/override-hardened.conf as of matrix-synapse 1.44.0-2.