SELinux is preventing Perl CGI script from accessing Oracle libraries

Question

I'm trying to configure SELinux on a Red Hat Enterprise Linux 6.2 web server that runs Apache 2.2.15 and Perl 5.10.1, and connects to remote Oracle databases. The Oracle 11.2g client is installed. The PHP scripts that access Oracle are working, but the Perl scripts are not. When SELinux is enforcing and I try to access the Perl scripts through my web browser, Apache's error logs show this message:

Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/Oracle.so' for module DBD::Oracle: libclntsh.so.11.1: cannot open shared object file: No such file or directory at /usr/lib64/perl5/DynaLoader.pm line 200.

Oddly, the audit log does not record any corresponding messages. However, when I run set SELinux to permissive mode, the Perl script works perfectly.

This is the output of ls -lZ on libclntsh.so.11.1:

-rwxr-xr-x. oracle oracle system_u:object_r:textrel_shlib_t:s0 /path/to/oracle/product/11.2.0/client/lib/libclntsh.so.11.1

Does anyone have any suggestions to fix this? I would like to be able to run the web server with SELinux.

UPDATE: After setting selinux to dontaudit, I got more output in audit.log. However, the module I created with audit2allow does not install. The output of semodule -i is: semodule: Failed on cgi_oracle!

cgi_oracle.te contains:

module cgi_oracle 1.0;

require {
    type httpd_log_t;
    type httpd_t;
    type httpd_sys_script_t;
    class process { siginh noatsecure rlimitinh };
    class file { read write };
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_log_t:file { read write };

#============= httpd_t ==============
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure };

Answer 1

A number of SELinux policies are flagged dontaudit so that they do not leave messages in the audit log. This is usually because they are policies that would just spam the log with useless entries, but sometimes developers dontaudit a denial rather than fixing the underlying problem. The policy you're hitting is almost certainly among these, since you aren't seeing any messages being logged in audit.log.

You can temporarily disable dontaudit by running:

semodule -DB

After you've discovered the cause of the problem, re-enable dontaudit with:

semodule -B

To build your policy once you've generated it, run:

make -f /usr/share/selinux/devel/Makefile

Answer 2

You can also try setroubleshoot.. it will also give you clues to what is being restricted and the commands to resolve the issue. Most of the time all you have to do is copy and paste exactly what is given.

yum install -y setroubleshoot

then

grep setrouble /var/log/messages

For example:

Aug  6 12:36:11 cnt3 setroubleshoot: [avc.ERROR] Plugin Exception catchall_boolean #012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/setroubleshoot/analyze.py", line 191, in analyze_avc#012    report = plugin.analyze(avc)#012  File "/usr/share/setroubleshoot/plugins/catchall_boolean.py", line 90, in analyze#012    man_page = self.check_for_man(b)#012  File "/usr/share/setroubleshoot/plugins/catchall_boolean.py", line 76, in check_for_man#012    man_page = name.split("_")[0] + "_selinux"#012AttributeError: 'tuple' object has no attribute 'split'
Aug  6 12:36:11 cnt3 setroubleshoot: SELinux is preventing /usr/libexec/gdm-session-worker from read access on the directory /root. For complete SELinux messages. run sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01

sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01

sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01
SELinux is preventing /usr/libexec/gdm-session-worker from read access on the directory /root.

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

If you believe that gdm-session-worker should be allowed read access on the root directory 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:

grep gdm-session-wor /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

Follow what the sealert -l tells you, and I think your problem should be solved. Hope that helps.

Answer 3

To correctly identify the problem - you must run test with SELinux permissive mode, otherwise you will need to run tests one by one and might take a time.

After, stop web service, be sure that your audit logs are empty or rotated, run web service, run scripts/test, check audit logs and write new policy.

As I understand your scripts want to access Oracle libraries for read, so you will need to add read permission for system_u:object_r:textrel_shlib_t:s0 on your application.

I don't know what is the labeling structure for Oracle, but I'm sure you can find out. Check audit2allow.