"SELinux prevented httpd reading and writing access to http files."

[DennyCrane]

SELinux prevented httpd reading and writing access to http files. Ordinarily httpd is allowed full access to all files labeled with http file context. This machine has a tightened security policy with the httpd_unified turned off, this requires explicit labeling of all files. If a file is a cgi script it needs to be labeled with httpd_TYPE_script_exec_t in order to be executed. If it is read-only content, it needs to be labeled httpd_TYPE_content_t, it is writable content. it needs to be labeled httpd_TYPE_script_rw_t or httpd_TYPE_script_ra_t. You can use the chcon command to change these contexts. Please refer to the man page "man httpd_selinux" or FAQ "TYPE" refers to one of "sys", "user" or "staff" or potentially other script types.

Allowing access:

Changing the "httpd_unified" boolean to true will allow this access: "setsebool -P httpd_unified=1"

The command noted above has had no effect. I've also made sure that everyone can read/write...

I've used this script before. Normally, all I have to do temporarily change the permission of my html directory files, but it's not working this time...

Suggestions?

[SlowJet]

There is three separate subjects in your post but no detailed information of the current www/html/

1. Does it have the correct selinux labels?
2. Did you relabel anything when it was off?
3. Did you relabel the system after turning it back on?

Permissions are not part of SElinux. Permissions are part of the F/S access security.

"Normally, all I have to do temporarily change the permission of my html directory files"
MY as in /home/you/myhtmllabeleddir (that would be another boolean on.)
or you chmod the permissions and think that is going to change the SELinux labels? No it will not.

So do a
touch /.autorelabel and then show the www/html/myfiles context and permissions
if it still does not work.

ls -halZ

SJ

[DennyCrane]

Never mind. Thank you for taking the time to reply.

[Ex_Soft]

I have analogical problem. I unpacked Joomla to /var/www/html/joomla. After that I did

#cd /var/www/html/joomla
#chown -R apache:apache .
#setsebool -P httpd_unified=1
#touch /.autorelabel

Originally Posted by ls -halZ /var/www/html/joomla

drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t:s0 ..
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 administrator
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 cache
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 CHANGELOG.php
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 components
-rwxr--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 configuration.php
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 configuration.php-dist
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 COPYRIGHT.php
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 CREDITS.php
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 htaccess.txt
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 images
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 includes
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index2.php
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.php
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 installation.org
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 INSTALL.php
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 language
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 libraries
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 LICENSE.php
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 LICENSES.php
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 logs
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 media
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 modules
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 plugins
-rw-r--r-- apache apache unconfined_u:object_r:httpd_sys_content_t:s0 robots.txt
drwx---rwx apache apache unconfined_u:object_r:httpd_sys_content_t:s0 templates
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 tmp
drwxr-xr-x apache apache unconfined_u:object_r:httpd_sys_content_t:s0 xmlrpc

But the problem exists still. That must I do yet? Is there any acceptable solution of this problem except it? (I know it isn't good)

[domg472]

With some of these PHP scripts some more booleans need to be toggled. SEtroubleshoot interprets the denial incomplete.

What you should do is:

1. list you HTTPD booleans:

getsebool -a | grep httpd

allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> off
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> off
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_ssi_exec --> off
httpd_tty_comm --> off
httpd_unified --> off
httpd_use_cifs --> off
httpd_use_nfs --> off

2. Make sure the following 3 booleans are set to "on":

httpd_enable_cgi --> on
httpd_unified --> on
httpd_builtin_scripting --> on

With:

setsebool -P httpd_enable_cgi on
setsebool -P httpd_unified on
setsebool -P httpd_builtin_scripting on

So if you are running a PHP webapp, and setroubleshoot advices you to set httpd_unified 1, but it has no effect, then set the 3 booleans mentioned above.

[Ex_Soft]

Originally Posted by getsebool -a | grep httpd

allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> off
httpd_enable_cgi --> off
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_ssi_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_nfs --> off

Originally Posted by domg472

setsebool -P httpd_enable_cgi on

THNX

P.S. But these booleans are global settings. May they tune to the concrete files like this?

[domg472]

The httpd_unified policy allows httpd FULL access to ALL http sys content.

example:

httpd_t CAN write to httpd_sys_content_t

normally httpd cannot do this (normally httpd can only write to httpd_sys_content_rw_t and httpd_user_content_rw_t)

The httpd_unified is NOT the best way to handle these issues in some cases.

when httpd_unified might be helpful:

If you only have one PHP webapp on your server. (apache is dedicated for a single (php) webapp

when httpd_unified is not helpful:

if run several different webapps/sites on your server. (apache runs different types of webapps)

If you run several PHP webapp on your httpd server then you should just label the location that apache needs to write to with type httpd_sys_content_rw_t. and you should label content that apache needs to be able to execute with type httpd_sys_script_exec_t.

This, unlike httpd_unified, allow apache to ONLY write/execute those locations and NOT to ALL httpd content.

httpd_unified was designed for scripting languages like PHP that act different then CGI.

PHP scripts get run with httpds privileges.
CGI, like for example perl, can run with their own privileges.

So to sum this all up.

The httpd_unified solution works but is very coarse grained. In many cases its not the preferred solution.

Often you can solve your issues with proper labelling of the various content.

httpd_sys_content_t (system content (var/www) read only to apache)
httpd_sys_content_rw_t (system content (var/www) read write to apache)
httpd_sys_script_exec_t (system content (var/www) executable by apache)

httpd_user_content_t (user content ($HOME/public_html) read only to apache)
httpd_user_content_rw_t (user content ($HOME/public_html) read write to apache)
httpd_user_script_exec_t (user content ($HOME/public_html) executable by apache)

proper labelling is the best was to solve your issues, but can sometimes be a bit complicated.

for example:

webapp want to write content in /var/www/webapp/write
semanage fcontext -a -t httpd_sys_content_rw_t "/var/www/webapp/write(/.*)?"
restorecon -R -v /var/www/webapp/write

apache wants to execute /var/www/webapp/webapp.php
semanage fcontext -a -t httpd_sys_script_exec_t /var/www/webapp/webapp.php
restorecon -R -v /var/www/webapp/webapp.php

apache wants to write to /home/joe/public_html/webapp/write
chcon -R -t httpd_user_content_rw_t /home/joe/public_html/webapp/write

apache wants to execute a webapp in /home/joe/public_html/webapp/webapp.php
chcon -t httpd_user_script_exec_t /home/joe/webapp/webapp.php

The fact that PHP has to run as httpd makes PHP in my view a less interesting language to use.
CGI, python, perl, shell can be restricted. these script can run in their own environment and so they can be contained.

But even with PHP, SELinux help a lot with security. because the PHP webapps are confined to the httpd "sandbox" (domain)

The problem is that if you run several webapps in the same domain then the webapps can affect eachother. (the have the same permission and they can access eachothers resources (files)
So if you have two webapps, and have httpd_unified set, and one of the two webapps gets compromised, then the compromised webapp can write to the other webapp (affect it)

conclusion:
preferably try to make your webapp work without using the httpd_unified boolean. use proper labelling instead