Created attachment 676840 [details, diff] User Patch to fix the issue After updating selinux to 2.20200818-r2 "/etc/init.d/asterisk" can't be executed by the admin user any longer: spinx ~ # /etc/init.d/asterisk status bash: /etc/init.d/asterisk: Permission denied Dec 5 14:03:42 spinx kernel: audit: type=1400 audit(1607173422.869:306): avc: denied { execute } for pid=6242 comm="bash" name="asterisk" dev="sda3" ino=21071264 scontext=staff_u:sysadm_r:sysadm_t tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=file permissive=0 Dec 5 14:03:42 spinx kernel: audit: type=1400 audit(1607173422.869:307): avc: denied { execute } for pid=6242 comm="bash" name="asterisk" dev="sda3" ino=21071264 scontext=staff_u:sysadm_r:sysadm_t tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=file permissive=0 The problem can be solved by changing the file type of "/etc/init.d/asterisk" from "asterisk_initrc_exec_t" to "initrc_exec_t". But the change can't be made relabel-persistent via "semanage fcontext" since at least sec-policy/selinux-asterisk-2.20200818-r2 is explicitly setting it. (Identical entry is not accepted, deletion not possible and a entry for "all files" ignored by the built-in more specific rule.) I fixed the issue now with the attached user patch (located in /etc/portage/patches/sec-policy/selinux-asterisk) Looking in my /etc/init.d folder the issue other packages seem to have the same issue: -rwxr-xr-x. 1 root root system_u:object_r:acpid_initrc_exec_t 436 Oct 12 18:40 acpid -rwxr-xr-x. 1 root root system_u:object_r:auditd_initrc_exec_t 2054 Dec 5 10:25 auditd -rwxr-xr-x. 1 root root system_u:object_r:iptables_initrc_exec_t 4384 Aug 28 19:00 iptables -rwxr-xr-x. 1 root root system_u:object_r:ntpd_initrc_exec_t 489 Jul 11 18:27 ntpd -rwxr-xr-x. 1 root root system_u:object_r:rngd_initrc_exec_t 1683 Oct 12 18:40 rngd But since I don't call the services manually and the start at boot is working I did not look into that. (The scripts can't be called manually of course, too.)
If you're running an init script directly, try using run_init. This allows transitioning from the sysadm_t context into various initrc contexts. I don't currently have an SELinux installation to test this on, but this is what I remember from days past. See: https://wiki.gentoo.org/wiki/SELinux/Tutorials/Linux_services_and_the_system_u_SELinux_user#Linux_service_scripts
run_init is asking for the login user (which is not root for me) password to authenticate but my login user has no password due to using ssh keys only... Now when I set a password "run_init /etc/init.d/asterisk status "is indeed working. Looks like a potential workaround when I would update the pam config. But maybe you are meaning rc-service instead of run_init? That can also be used to start/stop/check services in openrc. That is also only working when /etc/init.d/asterisk is set to initrc_exec_t on my system: spinx ~ # chcon -t asterisk_initrc_exec_t /etc/init.d/asterisk spinx ~ # rc-service asterisk status * rc-service: Permission denied spinx ~ # chcon -t initrc_exec_t /etc/init.d/asterisk spinx ~ # rc-service asterisk status Authenticating root. Password: * status: started spinx ~ #
From the original post I had assumed there was a reason why you had chosen to run the script directly, rather than through openrc. However, if running through openrc works, it looks to me like this is working as intended. Denying access to running the init scripts directly looks to be a deliberate choice rather than a bug. It makes sense for each init script to run in its own context so that they cannot interact without going through the policy.
It's only working with rc-service when I've changed the type to initrc_exec_t. The "official" setting at the moment is asterisk_initrc_exec_t, so it's NOT working when running the script via rc-service without some woraround. (It works during system start/stop but not when called interactively.) Using rc-service or call the init script directly makes no difference. (And to my best knowledge calling the script directly is still allowed and even common on Openrc.) There may well be a good reason to have the init script labeled as asterisk_initrc_exec_t and the root cause is whatever has been changed in the selinux policy blocking that.
(In reply to Alexander Wetzel from comment #4) > It's only working with rc-service when I've changed the type to > initrc_exec_t. > The "official" setting at the moment is asterisk_initrc_exec_t, so it's NOT > working when running the script via rc-service without some woraround. (It > works during system start/stop but not when called interactively.) Apologies, that's my reading mistake. > Using rc-service or call the init script directly makes no difference. (And > to my best knowledge calling the script directly is still allowed and even > common on Openrc.) > > There may well be a good reason to have the init script labeled as > asterisk_initrc_exec_t and the root cause is whatever has been changed in > the selinux policy blocking that. Can you post the AVC log of the rc-service denial? That might shed some more light on the intended context transitions.
Here is what I get when calling "rc-service asterisk status": Dec 5 20:56:18 spinx kernel: audit: type=1400 audit(1607198178.887:430): avc: denied { execute } for pid=7051 comm="rc-service" name="asterisk" dev="sda3" ino=21071264 scontext=staff_u:sysadm_r:sysadm_t tcontext=system_u:object_r:asterisk_initrc_exec_t tclass=file permissive=0
