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.