systemd hardening options

[juju4]

Expand hardening options on systemd config following https://www.freedesktop.org/software/systemd/man/systemd.exec.html

No impact in my setup but likely depends.

Note that SystemCallFilter deny list does not seem to apply correctly, be it as one-liner or one group per line. Either should work normally. SystemCallFilter allow list seems to always result in node_explorer process to be killed and may need more granular value than groups.

This brings systemd-analyze security node_exporter Overall exposure level to 3.3 while existing one is 7.7.

[sdarwin]

That's a very large systemd config file. It looks complex to maintain. Here is a question - if this type of configuration represented "best practices", then wouldn't popular distributions of software such as nginx, apache, mysql, postgres and other software distributed by Debian or Ubuntu have systemd config files with similar levels of security? Are there many examples of official software packages that look this way?
There is another alternative, which is to allow the user to override the template. Set the template name "node_exporter.service.j2" as a variable in defaults/main.yml. Modify as necessary. When running the playbook, place an alternative template in playbook_dir/templates.

[juju4]

IMHO, this is not difficult to maintain, especially more in the context of a monitoring/read-only application which I believe where all the prometheus exporters are falling. Initial work is enabling (or disabling) line by line each feature set reported by systemd-analyze security <service> and see if service starts or if any error/warning appearing. The longer part is validating application functionalities, the base/obvious one (easier part) and the less obvious ones, optional or whatever and test on multiple distributions.

As for the number of config options, that's more related to the evolution of systemd over time I believe. Most documentation and implementation stay on the older/"easier" settings. That's not necessarily adding complexity. If application does not use any linux capabilities, there should be no problem to blocked all of them.

IPAddressAllow is a best practice default to avoid people exposing to Internet without paying attention.

I'm using override when upstream package has a systemd unit. Most exporter projects don't seem to have and only rely on deployment tools like ansible role. I can certainly add a variable to enable extra systemd hardening or not but I would prefer, that after some testing, it is on by default. IMHO, most people don't review their security setup/options and as a result, end compromised.

I tried to get a look on failed tested but not clear to me if related to change (galaxy error or else)

Other examples of systemd hardening https://github.com/juju4/ansible-harden-systemd

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SuperQ]

This role has been deprecated in favor of a the prometheus-community/ansible collection.