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