0

I have a Type=simple /etc/systemd/system/custom.service. It has ExecStart=/root/scripts/custom.sh. I use this to make various administration things happen automatically after boot. It has worked well up to Redhat 7.9, no selinux problems with selinux=enforcing set.

In RHEL 8.8, I receive an selinux AVC denial in /var/log/messages.

systemd[1]: Started custom service.
systemd[96691]: custom.service: Failed to execute command: Permission denied
systemd[96691]: custom.service: Failed at step EXEC spawning /root/scripts/custom.sh: Permission denied
systemd[1]: custom.service: Main process exited, code=exited, status=203/EXEC
systemd[1]: custom.service: Failed with result 'exit-code'.

SELinux is preventing /usr/lib/systemd/systemd from execute access on the file custome.sh. For complete SELinux messages run: sealert -l 84fa818f-e23a-4686-afb5-3f2399d0d6ea

setroubleshoot[96693]: SELinux is preventing /usr/lib/systemd/systemd from execute access on the file custom.sh.#012#012
*****Plugin catchall (100. confidence) suggests
**************************#012#012If you believe that systemd should be allowed execute access
on the custom.sh file by default.#012Then you should report this as a bug.#012You can generate a
local policy module to allow this access.
#012Do#012allow this access for now by executing:
#012# ausearch -c '(ation.sh)' --raw | audit2allow -M my-ationsh#012# semodule -X 300 -i my-ationsh.pp#012

so i know my /root/scripts/custom.sh script does not have a proper selinux context. But what should I use?

My /etc/systemd/system/custom.service has gotten systemd_unit_file_t automatically, so I believe that is all set.

My /root/scripts/custom.sh currently has unconfined_u:object_r:admin_home_t:s0.

In checking other ExecStart items with ls -ldZ from other services in that folder I see :

-rwxr-xr-x. 1 root root system_u:object_r:bluetooth_exec_t:s0      1375048 May 17  2022 /usr/libexec/bluetooth/bluetoothd
-rwxr-xr-x. 1 root root system_u:object_r:NetworkManager_exec_t:s0   67752 Feb 23 04:51 /usr/libexec/nm-dispatcher
-rwxr-xr-x. 1 root root system_u:object_r:avahi_exec_t:s0           146208 Nov  3  2020 /usr/sbin/avahi-daemon
-rwxr-xr-x. 1 root root system_u:object_r:xdm_exec_t:s0             471744 Dec 12  2022 /usr/sbin/gdm
-rwxr-xr-x. 1 root root system_u:object_r:modemmanager_exec_t:s0   2203464 Dec 13  2022 /usr/sbin/ModemManager
-rwxr-xr-x. 1 root root system_u:object_r:syslogd_exec_t:s0         742168 Jan 10 06:46 /usr/sbin/rsyslogd
-rwxr-xr-x. 1 root root system_u:object_r:timedatex_exec_t:s0        33984 Aug 12  2018 /usr/sbin/timedatex
  • Do I need to make a customservice_exec_t type context? If so, how?
  • I thought I came across bin_t being a context where I did not see a corresponding exec_t syntax for some service when I was searching. Is bin_t a good context to use to save me the overhead of creating a context?
  • What is proper convention here for what I am doing so that it will not go not working in the future because I did something improper? I'm required to have selinux=enforcing so setting it to permissive is not a solution.
1
  • Have you run ausearch -c '(ation.sh)' --raw | audit2allow -M my-ationsh followed by cat my-ationsh.te and see what SELinux policy suggests? It even tells you to run semodule -X 300 -i my-ationsh.pp to fix the issue. Commented Jun 28, 2023 at 21:12

1 Answer 1

3

Do I need to make a customservice_exec_t type context? If so, how?

You don't need to do this, it would be necessary only if you want to create very specific rules and be sure to control every type accessing it, which is time consuming to create and high maintenance. It looks like you just want to use low maintenance best selinux practices. Although you can check here how to do it.

I thought I came across bin_t being a context where I did not see a corresponding exec_t syntax for some service when I was searching. Is bin_t a good context to use to save me the overhead of creating a context?

Yes, bin_t is a good context to use here, it's a generic context giving execution permissions to a lot of contexts.

What is proper convention here for what I am doing so that it will not go not working in the future because I did something improper

You could copy your script to /bin and then restorecon -RF /bin/custom.sh, or grants your scripts folder the right context with:

semanage fcontext -a -t bin_t "/root/scripts(/.*)?"
restorecon -RF /root/scripts

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .