.SELinux no longer blocks PCP from restarting unresponsive PMDAs
Previously, a rule that allows `pcp_pmie_t` processes to communicate with Performance Metric Domain Agent (PMDA) was missing in the SELinux policy. As a consequence, SELinux denied the `pmsignal` process to restart unresponsive PMDAs. With this update, the missing rule has been added to the policy, and the Performance Co-Pilot (PCP) can now restart unresponsive PMDAs.
Description of problem:
Customer recognized selinux denials and reported the following log information:
# aureport -a | tail -n4
288. 10/24/2019 09:31:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72897
289. 10/24/2019 09:41:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72912
290. 10/24/2019 09:51:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72927
291. 10/24/2019 10:01:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 73054
# sealert -l 1f9b8db8-21e5-4cfb-8822-8a7df7976fe0
SELinux is preventing /usr/bin/bash from using the signal access on a process.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that bash should be allowed signal access on processes labeled pcp_pmcd_t by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'pmsignal' --raw | audit2allow -M my-pmsignal
# semodule -i my-pmsignal.pp
Additional Information:
Source Context system_u:system_r:pcp_pmie_t:s0
Target Context system_u:system_r:pcp_pmcd_t:s0
Target Objects Unknown [ process ]
Source pmsignal
Source Path /usr/bin/bash
Port <Unknown>
Host xx-xx-xxxx
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-252.el7.1.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name xx-xx-xxxx
Platform Linux xx-xx-xxxx 3.10.0-1062.4.1.el7.x86_64 #1 SMP
Wed Sep 25 09:42:57 EDT 2019 x86_64 x86_64
Alert Count 786
First Seen 2019-10-17 12:07:44 UTC
Last Seen 2019-10-24 09:51:03 UTC
Local ID 1f9b8db8-21e5-4cfb-8822-8a7df7976fe0
Raw Audit Messages
type=AVC msg=audit(1571910663.107:72927): avc: denied { signal } for pid=122835 comm="pmsignal" scontext=system_u:system_r:pcp_pmie_t:s0 tcontext=system_u:system_r:pcp_pmcd_t:s0 tclass=process permissive=0
Hash: pmsignal,pcp_pmie_t,pcp_pmcd_t,process,signal
Further digging reveled:
------------
Log for pmie on xx-xx-xxxx rotated Wed Oct 23 00:08:00 2019
pmie: PID = 96272, via local:
/usr/libexec/pcp/bin/pmsignal: line 123: kill: (95896) - Permission denied
[ ... ]
/var/log/messages-20191027.gz:Oct 24 10:11:03 xx-xx-xxxx pcp-pmie[96272]: Restart unresponsive PMDAs pmdaproc[4]@xx-xx-xxxx
Version-Release number of selected component (if applicable): -
How reproducible:
Hard to say. In my customers environment, on his CI/CD server, this is happening every 10 minutes.
Steps to Reproduce: n/a
Actual results:
SELinux denies pmsignal to restart unresponsive PMDAs.
Expected results:
While we are aware we need to find out the reason the specific PMDA (pmdaproc) gets unresponsive, it's a common scenario that pmsignal restarts unresponsive PMDAs, so it's something that should be allowed => pmsignal can kill unresponsive PMDAs, so they can be automatically restarted.
Additional info:
* I hope we can expect this to be fixed in latest RHEL 7.9.
* I'll discuss with the CU if we need it in 7.7 (last EUS) as well.
* It's (most) probably affecting RHEL8 as well, so may needs a clone to RHEL8 also.
* Customer case linked.
If I understand correctly, the permission is required for pcp-pmie to signal an unresponsive PMDAs pmdaproc. It was allowed in the following fedora/contrib commit:
commit 58de34f1d176c0311a37a52f5b4195798
Author: Lukas Vrabec <lvrabec>
Date: Fri Nov 25 14:02:04 2016 +0100
Allow pmie daemon to send signal pcmd daemon BZ(1398078)
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2020:3925
Description of problem: Customer recognized selinux denials and reported the following log information: # aureport -a | tail -n4 288. 10/24/2019 09:31:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72897 289. 10/24/2019 09:41:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72912 290. 10/24/2019 09:51:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 72927 291. 10/24/2019 10:01:03 pmsignal system_u:system_r:pcp_pmie_t:s0 62 process signal system_u:system_r:pcp_pmcd_t:s0 denied 73054 # sealert -l 1f9b8db8-21e5-4cfb-8822-8a7df7976fe0 SELinux is preventing /usr/bin/bash from using the signal access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that bash should be allowed signal access on processes labeled pcp_pmcd_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'pmsignal' --raw | audit2allow -M my-pmsignal # semodule -i my-pmsignal.pp Additional Information: Source Context system_u:system_r:pcp_pmie_t:s0 Target Context system_u:system_r:pcp_pmcd_t:s0 Target Objects Unknown [ process ] Source pmsignal Source Path /usr/bin/bash Port <Unknown> Host xx-xx-xxxx Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-252.el7.1.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name xx-xx-xxxx Platform Linux xx-xx-xxxx 3.10.0-1062.4.1.el7.x86_64 #1 SMP Wed Sep 25 09:42:57 EDT 2019 x86_64 x86_64 Alert Count 786 First Seen 2019-10-17 12:07:44 UTC Last Seen 2019-10-24 09:51:03 UTC Local ID 1f9b8db8-21e5-4cfb-8822-8a7df7976fe0 Raw Audit Messages type=AVC msg=audit(1571910663.107:72927): avc: denied { signal } for pid=122835 comm="pmsignal" scontext=system_u:system_r:pcp_pmie_t:s0 tcontext=system_u:system_r:pcp_pmcd_t:s0 tclass=process permissive=0 Hash: pmsignal,pcp_pmie_t,pcp_pmcd_t,process,signal Further digging reveled: ------------ Log for pmie on xx-xx-xxxx rotated Wed Oct 23 00:08:00 2019 pmie: PID = 96272, via local: /usr/libexec/pcp/bin/pmsignal: line 123: kill: (95896) - Permission denied [ ... ] /var/log/messages-20191027.gz:Oct 24 10:11:03 xx-xx-xxxx pcp-pmie[96272]: Restart unresponsive PMDAs pmdaproc[4]@xx-xx-xxxx Version-Release number of selected component (if applicable): - How reproducible: Hard to say. In my customers environment, on his CI/CD server, this is happening every 10 minutes. Steps to Reproduce: n/a Actual results: SELinux denies pmsignal to restart unresponsive PMDAs. Expected results: While we are aware we need to find out the reason the specific PMDA (pmdaproc) gets unresponsive, it's a common scenario that pmsignal restarts unresponsive PMDAs, so it's something that should be allowed => pmsignal can kill unresponsive PMDAs, so they can be automatically restarted. Additional info: * I hope we can expect this to be fixed in latest RHEL 7.9. * I'll discuss with the CU if we need it in 7.7 (last EUS) as well. * It's (most) probably affecting RHEL8 as well, so may needs a clone to RHEL8 also. * Customer case linked.