• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Issue SELinux preventing sh from executing ldconfig

G J Piper

Regular Pleskian
After upgrading to Obsidian today, I have an issue appearing in the logs over and over:

Code:
Oct 22 13:17:38 pcs-plesk-centos7-web-vm setroubleshoot: SELinux is preventing sh from execute access on the file ldconfig. For complete SELinux messages run: sealert -l 61e5cd70-f069-439d-9e7d-ea412d1db487
Oct 22 13:17:38 pcs-plesk-centos7-web-vm python: SELinux is preventing sh from execute access on the file ldconfig.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that sh should be allowed execute access on the ldconfig 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 'sh' --raw | audit2allow -M my-sh#012# semodule -i my-sh.pp#012

I followed the procedure to generate a local policy module in SELinux for this as it instructs, but it doesn't seem to stop the log entries. Tried restarting the server afterward -- no difference. I have SELinux runniong in "premissive" mode for now just so no unexpected trouble comes along due to these.

I don't seem to have any other symptoms I can see, but the log entries by the hundreds are annoying.

Any ideas?
 
Hello,

Could you post exact AVC messags from SELinux ? Becuse sh can be executed from almost everywhere.
 
Could you post exact AVC messags from SELinux ? Becuse sh can be executed from almost everywhere.

Yes. Absolutely.

Code:
SELinux is preventing sh from execute access on the file ldconfig.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that sh should be allowed execute access on the ldconfig file 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 'sh' --raw | audit2allow -M my-sh
# semodule -i my-sh.pp


Additional Information:
Source Context                system_u:system_r:sendmail_t:s0
Target Context                system_u:object_r:ldconfig_exec_t:s0
Target Objects                ldconfig [ file ]
Source                        sh
Source Path                   sh
Port                          <Unknown>
Host                          pcs-plesk-centos7-vm
Source RPM Packages           glibc-2.17-292.el7.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-252.el7.1.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     pcs-plesk-centos7-vm
Platform                      Linux pcs-plesk-centos7-vm
                              3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18
                              17:15:30 UTC 2019 x86_64 x86_64
Alert Count                   477
First Seen                    2019-10-22 05:16:58 PDT
Last Seen                     2019-10-23 06:28:32 PDT
Local ID                      61e5cd70-f069-439d-9e7d-ea412d1db487

Raw Audit Messages
type=AVC msg=audit(1571837312.811:3594): avc:  denied  { execute } for  pid=23165 comm="sh" name="ldconfig" dev="sda1" ino=25167011 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1

type=AVC msg=audit(1571837312.811:3594): avc:  denied  { read open } for  pid=23165 comm="sh" path="/usr/sbin/ldconfig" dev="sda1" ino=25167011 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1

type=AVC msg=audit(1571837312.811:3594): avc:  denied  { execute_no_trans } for  pid=23165 comm="sh" path="/usr/sbin/ldconfig" dev="sda1" ino=25167011 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:ldconfig_exec_t:s0 tclass=file permissive=1

type=SYSCALL msg=audit(1571837312.811:3594): arch=x86_64 syscall=execve success=yes exit=0 a0=1940b00 a1=1940db0 a2=1940bd0 a3=7ffe09f727a0 items=0 ppid=23164 pid=23165 auid=4294967295 uid=30 gid=31 euid=30 suid=30 fsuid=30 egid=31 sgid=31 fsgid=31 tty=(none) ses=4294967295 comm=ldconfig exe=/usr/sbin/ldconfig subj=system_u:system_r:sendmail_t:s0 key=(null)

Hash: sh,sendmail_t,ldconfig_exec_t,file,execute
 
Hello,

Rather strange: it seems some shell script is executed as part of mail sending. I don't remember same thing in Plesk. May be you have some customised sendmail wrappers or other mail things ?
 
Hello,

Rather strange: it seems some shell script is executed as part of mail sending. I don't remember same thing in Plesk. May be you have some customised sendmail wrappers or other mail things ?

I know what you mean. I don't have any custom sendmail wrappers.

I viewed other logs at the same time as the messages log to see if I could view it coinciding with some other funtion but I didn't see any. Nothing in the maillog or HTTP access or error logs seems to happen at the same time as the ldconfig errors.

In fact, if I turn SELinux to "enforcing" mode it doesn't even seem to break anything that I can find — email, websites, php all still work. No emails are attempting to send at the same time either.
 
Back
Top