devsec.hardenting.os_hardening breaks pmlogger_daily on Oracle Linux 8 (maybe RHEL 8 too)

[rfrush]

Describe the bug After applying devsec.hardening.os_hardening role with the default settings the /usr/libexec/pcp/bin/pmlogger_daily command (and pmlogger_daily.service) fails. pmlogger_daily is responsible for doing log rotation for pmlogger, and when it fails /var/log/pcp/pmlogger fills up the disk, ultimately causing system to misbehave.

Expected behavior /usr/libexec/pcp/bin/pmlogger_daily should work the same before and after the os hardening role is applied.

Actual behavior /usr/libexec/pcp/bin/pmlogger_daily records this in /var/log/pcp/pmlogger/pmlogger_daily.log

pmlogger_daily: [control.d/local:26]
Error: no pmlogger instance running for host "local:"
... logging for host "local:" unchanged
pmlogger_daily: [control.d/local:26]
Warning: skipping log rotation because we don't know which pmlogger to signal
pmlogger_daily: [control.d/local:26]
Warning: current volume of current pmlogger not known, compression skipped

Example Playbook

  become: true
  become_user: root
  collections:
    - devsec.hardening
  roles:
    - devsec.hardening.os_hardening
    - devsec.hardening.ssh_hardening
  vars:
    os_auth_pw_max_age: 99999
    os_auth_allow_homeless: true
    os_ignore_users: [ 'deployants' ]

OS / Environment

$ cat /etc/redhat-release Red Hat Enterprise Linux release 8.3 (Ootpa) $ cat /etc/oracle-release Oracle Linux Server release 8.3

Ansible Version

  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/mnt/is/home/frush/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.6/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.6.8 (default, Mar  9 2021, 15:28:46) [GCC 8.3.1 20191121 (Red Hat 8.3.1-5.0.1)]

Role Version

Additional context

[rfrush]

Oh, I did neglect to mention that the pmlogger.service does run as expected before and after the role is applied, and is verified to be running. The pmlogger_daily process appears to be unable to detect that it is running.

[rndmh3ro]

Since you mention that the pmlogger_daily appears to be unable to detect that the pmlogger service is running, try setting hidepid_option to 0 and reboot:

hidepid_option

    Default: 2 (on RHEL/CentOS7 0, see known limitations)
    Description: 0: This is the default setting and gives you the default behaviour. 1: With this option an normal user would not see other processes but their own about ps, top etc, but he is still able to see process IDs in /proc. 2: Users are only able too see their own processes (like with hidepid=1), but also the other process IDs are hidden for them in /proc.

[rfrush]

I'm going to accept that as a solution. My steps to repeat the problem didn't fail when hidpid_option was set to '0' Steps to repeat:

• starting with newly templated system...
• apply devsec.hardening.os_hardening
• reboot system
• run 'systemctl start pmlogger_daily' and see if it errors.

Another way to fix this might also to be to manually run /usr/libexec/pcp/bin/pmlogger_daily directly outside of the SystemD context. But setting the hidepid_option seems better from an automation standpoint.

[rfrush]

Just noting that these files set hidepid_option: 2

ansible-collection-hardening/roles/os_hardening/vars/Rocky_8.yml ansible-collection-hardening/roles/os_hardening/vars/Redhat_8.yml

ansible-collection-hardening/roles/os_hardening/vars/Redhat_7.yml has it set to '0'.

Might be worth another review.

[rndmh3ro]

There is a bug in RHEL7: https://github.com/dev-sec/ansible-collection-hardening/issues/364

If this bug is present in RHEL 8, too, then when can change hidepid there, too.

@rfrush did you experience the linked bug?

[dlouzan]

@rndmh3ro A while back we set hidepid_option: 0 on our Fedora servers (now a mix with AmazonLinux 2023) because we started getting ssh authentication log errors for sessions in the context of non-root users.

Digging into this, we found that there's a clear statement from systemd's team in multiple comments that using proc isolation is not supported at all:

https://github.com/systemd/systemd/issues/29893#issuecomment-1798030108

I am sorry, but no. global "hidepid" doesn't really work on a general purpose Linux system, because tons of tools need to check /proc/, for example pid1, journald, polkit and similar. We do not support it, full stop.

Should the defaults be changed to 0?