Add restrictions to the node_exporter systemd service to increase security of the running program

[thomasrahimi]

In order to increase runtime security of node exporter on systemd enabled Linux distributions, the appropriate options to limit the process' impact on the system have been adapted. The idea behind my contribution at this point is, that improvements in the example file may trickle down to the Linux distributions providing the packages of node_exporter. By providing the distributions with a tested and proven set of required permissions and capabilities, it may be easier for package maintainers to provide appropriate service files for node_exporter.
The options added in my pull request have been tested in my productive environment and are conformant to the documentation of the systemd project (cp. https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html?__goaway_challenge=meta-refresh&__goaway_id=6b170467973a444f062cf79f399a6a98). Using these options significantly improves the security standing of node_exporter.service, as rated by the benchmarking tool systemd-analyze security.

[discordianfish]

I don't think we can maintain this unless we have automated tests for this. Like when we add a collector that requires a different syscall etc, it would possibly break this unit - right?

[thomasrahimi]

I don't think we can maintain this unless we have automated tests for this. Like when we add a collector that requires a different syscall etc, it would possibly break this unit - right?

Thanks for the suggestion of contributing a test case for this systemd file. Is there any directory or external repository, where unit tests triggered as part of the git process are stored? Yet, I doubt that such tests executed in the build environment, will catch missing permission in situations, where hardware or operation modes are used by node-exporter, which do not exist in the test setup.
Thus, my question would be, do you have any kind of collection of all relevant syscalls performed by node-exporter? If not, I will dig myself into the question, on how to get the full set of possible syscalls performed by an application under Linux.