Invalid systemd configuration options used

[treydock]

Seems some of the systemd unit file options passed are not valid on RHEL7 systemd. I wasn't sure how to best go about making this module only use supported flags. There is the systemd_version fact if it could be determined which options are supported for a certain version. What OS were the new parameters from #415 pulled from and what systemd version was that?

Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:17] Unknown lvalue 'ProtectHostname' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:18] Unknown lvalue 'ProtectControlGroups' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:19] Unknown lvalue 'ProtectKernelModules' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:20] Unknown lvalue 'ProtectKernelTunables' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:21] Unknown lvalue 'LockPersonality' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:22] Unknown lvalue 'RestrictRealtime' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:23] Unknown lvalue 'RestrictNamespaces' in section 'Service'
Feb 18 11:20:25 prometheus01 systemd: [/etc/systemd/system/prometheus.service:24] Unknown lvalue 'MemoryDenyWriteExecute' in section 'Service'

Systemd version:

# systemctl --version
systemd 219
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN

Affected Puppet, Ruby, OS and module versions/distributions

• Distribution: RHEL 7.7
• Module version: master

[dhoppe]

The following code should work:

...
ProtectSystem=full
ProtectHostname=true
PrivateDevices=yes
CapabilityBoundingSet=
<% if versioncmp(fact('systemd_version'), '227') >= 0 { -%>
NoNewPrivileges=true
<% } -%>
<% if versioncmp(fact('systemd_version'), '231') >= 0 { -%>
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
<% } -%>
<% if versioncmp(fact('systemd_version'), '232') >= 0 { -%>
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
<% } -%>
<% if versioncmp(fact('systemd_version'), '233') >= 0 { -%>
RestrictNamespaces=yes
<% } -%>
<% if versioncmp(fact('systemd_version'), '235') >= 0 { -%>
LockPersonality=true
<% } -%>
<% if versioncmp(fact('systemd_version'), '242') >= 0 { -%>
ProtectHome=true
<% } -%>
...

However, I do not know how we are going to put something like that in the files under spec/fixtures/files/*.

[slvr32]

The following code should work:
...
CapabilityBoundingSet=

Having this CapabilityBoundingSet key without any values set seems to keep prometheus from starting on (some?, e.g. OEL8) systems, when attempting to run prometheus on a privileged port, e.g. 80 for the rest of the details below...

For root:root manage user/group overrides, just the CapabilityBoundingSet= seems to cause a failed start.

For the default prometheus:prometheus user/group, and setcap tweaks on the prometheus binary, e.g.

$ sudo setcap 'cap_net_bind_service=+ep' /opt/prometheus-2.28.0-linux-amd64/prometheus

more of the options cause a failed start, and the following seems to be a working set, noting the entries that are commented out...

#NoNewPrivileges=true
ProtectHome=true
ProtectSystem=full
ProtectHostname=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectKernelTunables=true
#LockPersonality=true
#RestrictRealtime=yes
#RestrictNamespaces=yes
#MemoryDenyWriteExecute=yes
PrivateDevices=yes
#CapabilityBoundingSet=

A nice solution might be to include these 'lockdown' options based on some kind of strict security setting set to true or false.

I noticed that these 'lockdown' options were part of a commit on Jan 6, 2020, and were likely first included in the 8.2.0 release.

If you run prometheus as prometheus:prometheus, on the default 9090 port, these 'lockdown' options don't cause any of the startup issues above, IIRC.

Also, see #568 for more detail...

[TheMeier]

Since we just dropped EL7 support I guess this is no longer relevant. Please re-open if I am wrong ;)