This bug was initially created as a copy of Bug #2039658

I am copying this bug because:

Also applies to RHEL8

Description of problem:

Confined users mapped to sysadm_u SELinux user cannot execute "service xxx status" or "service xxx restart" commands, as shown in the examples below:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
[sysadm@vm-confined8 ~]$ service foo status
env: /etc/init.d/foo: Permission denied
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

The root cause is missing rules to allow the transition to initrc_t to happen when "service" internally executes /etc/rc.d/init.d/xxx script.
Note: on RHEL7 (BZ #2039658) adding a rule was sufficient to make this work (see the "Additional info" in the BZ), but it doesn't seem the case on RHEL8.

Version-Release number of selected component (if applicable):

selinux-policy-3.14.3-80.el8_5.2.noarch

How reproducible:

Always

Steps to Reproduce:
1. Map a user to sysadm_u

2. Create a SysV initscript /etc/rc.d/init.d/foo

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
#!/bin/sh
#

1. foo: FOO SysV initscript
   #
2. chkconfig: 345 97 03

case "$1" in
start)
echo "START called"
;;
stop)
echo "STOP called"
;;
restart)
echo "RESTART called"
;;
status)
echo "STATUS called"
;;
reload)
echo "RELOAD called"
;;
*)
exit 2
esac
exit 0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

3. Make it executable and a proper SysV initscript

1. chmod +x /etc/rc.d/init.d/foo
2. restorecon -Fv /etc/rc.d/init.d/foo

4. Try executing "service foo status" command

Actual results:

No AVC, but Permission denied
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
env: ‘/etc/init.d/foo’: Permission denied
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Expected results:

Proper execution

Additional info:

SysV initscripts are still supposed to work fine on RHEL8, per /etc/rc.d/init.d/README note.

Note that "service xxx status" can be different than "systemctl status xxx" for SysV initscripts: it's SysV initscript implementation dependent, e.g. "service network status" output is different than "systemctl status network".
Hence using "systemctl status xxx" cannot be considered as a workaround.