Harden PCP systemd services

[orasagar]

Issue Description

PCP systemd units currently get high systemd-analyze security exposure scores.

Observed:

pmcd.service                       9.7 UNSAFE
pmie.service                       9.7 UNSAFE
pmlogger.service                   9.7 UNSAFE
pmproxy.service                    9.7 UNSAFE
pmlogger_check.service             9.1 UNSAFE
pmlogger_daily.service             9.1 UNSAFE
pmlogger_daily_report.service      9.1 UNSAFE
pmlogger_farm.service              9.1 UNSAFE
pmlogger_farm_check.service        9.6 UNSAFE
pmie_check.service                 9.1 UNSAFE
pmie_daily.service                 9.1 UNSAFE
pmie_farm.service                  9.1 UNSAFE
pmie_farm_check.service            9.6 UNSAFE
pmfind.service                     9.6 UNSAFE

The units appear to lack common systemd hardening options such as NoNewPrivileges=, ProtectSystem=, ProtectHome=, PrivateTmp=, RestrictNamespaces=, RestrictSUIDSGID=,
SystemCallArchitectures=, and a narrowed CapabilityBoundingSet=.

Please review the PCP service files and add least-privilege hardening where possible, while preserving required host-metric collection behavior. For paths that need writes, use
explicit allow-lists such as /var/lib/pcp, /var/log/pcp, and /run/pcp.

Operating System

Oracle linux

Architecture

x86_64

PCP Version

No response

Component

No response

Steps to Reproduce

No response

Additional Information

No response

[kmcdonell]

OK, this is all new to me ... but with not much effort I was able to reduce the pmlogger.service exposure score to 2.0 OK.
I think the same settings could be used for everything except pmcd, pmproxy and maybe pmfind.
Do we need to aim lower than 2.0, or is that enough to get PCP's head below the parapet?

[kmcdonell]

I'm not sure how useful any of this is in practice ... on bozo, changing UMask to 077 in the pmlogger.service file made NO DIFFERENCE to the mode of the created PCP archive files.

[kmcdonell]

OK, I am now going to propose we DO NOTHING here.

Whatever the mechanisms this systemd service hardening is using, they absolutely SUCK in terms of performance.

When I "harden" the pmcd.service file, the execution time for qa/966 goes from 17sec to 89sec. And I've observed similar slowdowns in all the QA tests I've been running,so this is not going to fly.

Perhaps @orasagar you could give us some indication of what push-back is going to happen if we don't do anything here.

On bozo 77 of 113 installed services are reported as UNSAFE by systems-analyze so we're in good company.

My overall impression is that this is another piece of systemd fluff that is adding complexity for no added value ... and yes I do not like systemd.

[orasagar]

@kmcdonell i'm not sure what should i say here,we definetly don't want performance to be degraded .

As companies are going for security stuff they want as much possible ,but i would say score of 6-7 would be ideal and sweet spot

[kmcdonell]

@orasagar OK, I'll revisit this after the pending release (it is too late in this cycle).
The 6-7 score target is good, so I have something to aim for ... my initial guess would be that the system call filtering is the most likely to be the cause of the obscene slow-down.

[kurik]

I propose a minimalist patch to systemd units, which according to my test runs have no impact on PCP functionality and no impact on the test-suite. See #2655