SELinux interfering with Apache / PHP

Question

On my installation of CentOS 7, SELinux is enabled by default. This is preventing Apache from properly reading PHP files in the standard /var/www/html document root (the browser is blank when displaying web pages containing PHP script). When I disable SELinux the pages display normally.

Is there some way of setting SELinux to allow Apache to access PHP files from the document root? I would rather not disable SELinux entirely given that CentOS clearly believes it is a desirable security addition.

Solution 1

I don't do much SELinux, but you can try

semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/html(/.*)?'

restorecon -R -v /var/www/html/

That allows Apache to execute PHP scripts in that directory, and persists after a reboot.

If you use MySQL, you may have to do the same for that. SELinux: Letting Apache talk to MySQL on CentOS may help

Solution 2

Running audit2allow < /var/log/audit/audit.log confirmed that httpd was being blocked by SELinux (see this link). The solution was to create and apply a policy module using the following steps:

1. As root, run the command audit2allow -a -M my_httpd (replace 'my_httpd' with whatever name you prefer).
2. Again as root, run the command semodule -i my_httpd.pp to install the module.

After I followed these steps Apache was able to run PHP scripts on my server without difficulty. Restart of the server does not destroy the changes.

Content of module file (my_httpd.te):

module my_httpd 1.0;
require {
    type admin_home_t;
    type httpd_t;
    class file { read getattr open };
}
#============= httpd_t ==============
allow httpd_t admin_home_t:file { read getattr open };

Comments

[Grant_Bailey]

Michael, I get a 'command not found', is some sort of package required?

[Michael Hampton]

It's the policycoreutils-python package. Have you had a chance to read the documentation? You should do that soon.

[Grant_Bailey]

Michael, the material you linked was valuable and provided me with the solution which I will post as an answer. Thanks again.

[kbulgrien]

Though it doesn't deal with PHP directly, this answer might help as it surveys a number things related to apache and SELinux : serverfault.com/a/551801/101931

[030]

stackoverflow.com/questions/15395845/…

[Grant_Bailey]

Yes I saw that but it refers to files outside the document root. I would have expected a less complex procedure for files within the document root.

[mvermaes]

Out of curiosity, are you able to share the contents of the module you created? It seems unusual that you would need to build a custom module for php files in the default docroot. Maybe the files were moved into the directory and don't have the proper context, in which case the restorecon command from bhavicp's answer might resolve the issue.

[Michael Hampton]

Yes, it seems very unlikely that you would have needed a custom policy module. More likely a simple boolean, or your files simply had the wrong contexts to begin with.

[Grant_Bailey]

Yes, the module consists of the two files my_httpd.pp (binary file) and my_httpd.te, the contents of which I will have to post separately.

[Grant_Bailey]

... sorry, module contents appear in my answer which has been edited.

[user9517]

You're doing development as root ?

[Michael Hampton]

Nope, you didn't need this policy at all. Your file contexts were just wrong and you needed to run restorecon.

[Grant_Bailey]

Michael, are you able to suggest a way of reversing what I did before (audit2allow / semodule commands) so that I may run the process bhavicp suggested.

[mvermaes]

In case it's still of use: You can unload the custom module with semodule -r my_httpd. audit2allow created the custom module's files, which you can delete (my_httpd.te and my_httpd.pp). Then run restorecon -R -v /var/www/html/