CentOS 6: PHP can not load gdchart.so and oci8.so compiled by me

centoscentos6PHPselinux

I have been trying to add 2 PHP extensions to a freshly installed CentOS 6.0 Linux server, but get the error messages in /var/log/httpd/error_log:

[notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/gdchart.so' - /usr/lib64/php/modules/gdchart.so: undefined symbol: php_gd_gdFontMediumBold in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/oci8.so' - libnnz11.so: cannot enable executable stack as shared object requires: Permission denied in Unknown on line 0
[notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.3.2 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.2 Python/2.6.5 mod_perl/2.0.4 Perl/v5.10.1 configured -- resuming normal operations

I did run

# chcon system_u:object_r:lib_t:s0 /usr/lib64/php/modules/oci8.so
# chcon system_u:object_r:lib_t:s0 /usr/lib64/php/modules/gdchart.so
# ls -alZ /usr/lib64/php/modules/

-rwxr-xr-x. root root system_u:object_r:lib_t:s0       curl.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       dom.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       fileinfo.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       gdchart.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       gd.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       json.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       oci8.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       pdo_pgsql.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       pdo.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       pdo_sqlite.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       pgsql.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       phar.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       sqlite3.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       wddx.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       xmlreader.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       xmlwriter.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       xsl.so
-rwxr-xr-x. root root system_u:object_r:lib_t:s0       zip.so

Here is how I compiled both modules:

1) For oci8.so – setup /etc/tnsnames.ora and then:

# rpm -Uvh oracle-instantclient11.2-basic-11.2.0.2.0.x86_64.rpm
# rpm -Uvh oracle-instantclient11.2-devel-11.2.0.2.0.x86_64.rpm
# pecl install oci8 (entered: instantclient,/usr/lib/oracle/11.2/client64/lib there)

2) For gdchart.so:

# yum install gd-devel php-devel gcc
# wget http://pecl.php.net/get/gdchart-0.2.0.tgz
# tar xvfz $!
# cd $!
# ./phpize
# ./configure
# make && make install

Does anybody please have an idea, what am I missing?

Using both libs (Oracle instant clicent and GDChart) from commandline works ok.

UPDATE:

When I switch SELinux off by putting SELINUX=permissive into /etc/selinux/config and reboot, the oci8.so loads, but gdchart.so still has a bug.

So I guess my question is: how to enable SELinux back and still being able to use oci8.so? Please share your experience here – if you already struggle with Oracle + PHP + CentOS/RHEL 6.

UPDATE 2:

When starting Apache, I see in /var/log/audit/audit.log:

type=AVC msg=audit(1316698464.300:51213): avc:  denied  { execstack } for  pid=2833 comm="httpd" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:system_r:httpd_t:s0 tclass=process
type=SYSCALL msg=audit(1316698464.300:51213): arch=c000003e syscall=10 success=yes exit=0 a0=7fff95f4b000 a1=1000 a2=1000007 a3=7f5e22611000 items=0 ppid=1 pid=2833 auid=10116 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=34 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Best Answer

Run the following command as root and try again:

# setsebool -P allow_execstack 1

You also can enable executable stack for only oci8.so with:

# execstack -c /usr/lib64/php/modules/oci8.so

Related Solutions

Redhat Apache fast-cgi selinux permissions

Running FastCGI your way leaves a big security hole: the PHP interpreter is run as user "httpd" (at least I can't see anything about suexec here).

We have a working setup with SELinux and PHP as FastCGI here at CentOS 6, but it was really tricky to get everything working.

A few tips for the start:

you don't need to reboot to disable/enable selinux - just use the command "setenforce 0" or "setenforce 1" :)
always try to get everything working with SELinux disabled, then enable it and have a look at audit.log

Here we go:

enable suexec
change SELinux type for php.fcgi to httpd_fastcgi_script_exec_t
your FastCGI starter (php.fcgi) should not be writable by the user owning it (otherwise he can tweak many settings and limits). Give it the "immutable" flag: chattr +i php.fcgi

suexec has some trouble with FastCGI, so we have to make it permissive:

yum install policycoreutils-python
semanage permissive -a httpd_suexec_t

Good luck!

Centos – Configure selinux to allow openldap on CentOS 6.4

If you filter the audit logs through audit2allow(1) and audit2why you'll get an approximate idea of what is happening:

#============= slapd_t ==============
allow slapd_t self:capability sys_nice;
allow slapd_t var_log_t:file { write read };
------------------------------------

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.408:3263): avc:  denied  { sys_nice } for  pid=1492 comm=slapd capability=23  scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:system_r:slapd_t:s0 tclass=capability

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

type=AVC msg=audit(1372888328.424:3264): avc:  denied  { read } for  pid=1493 comm=slapd name=log.0000000001 dev=dm-0 ino=263969 scontext=unconfined_u:system_r:slapd_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file

    Was caused by:
            Missing type enforcement (TE) allow rule.

            You can use audit2allow to generate a loadable module to allow this access.

Checking labeling

It is unlikely a label restore prevents you from starting a service if SELinux is in permissive mode. Also, why the -F switch?

To know if you have to restore the labeling of a directory or file, first find out what context a file or directory is supposed to have:

# matchpathcon /etc/openldap/
/etc/openldap   system_u:object_r:etc_t:s0

Then list its security context:

# ls -ldZ /etc/openldap/
drwxr-xr-x. root root system_u:object_r:etc_t:s0       /etc/openldap//

In this example, no further action is needed.

With regards to your issue, the problem is not labeling per se, but a missing type enforcement rule, i.e., a rule that allows a labeled process to transition from one confined domain to another, or to read files with an specific label, for example.

Creating an SELinux module

You can try to build a module that allows the slapd_t to perform the operations which appeared in the audit.log. It is probable that you need further adjustments in your code. Use audit2allow, and make for this task. All commands are very well documented in their respective manpages. The process will look roughly like this (after copying the relevant messages into audit.txt):

audit2allow -i audit.txt -m slapd -o slapd.te
make -f /usr/share/selinux/devel/Makefile load

Also, check if a bug report for the SELinux policy regarding this issue already exists.