SELinux results in Apache 403 error resolution

The DocumentRoot is located under/var/www/html to access

However, the DocumentRoot is located in a different directory (for example,/webroot) and forbidden is present. The relevant part of the./etc/httpd/conf/httpd.conf is this:

Alias/query "/home/query"

<directory "/home/query" >

Options Indexes MultiViews

AllowOverride None

Order Allow,deny

Allow from all

</Directory>

However, when you enter: http://localhost/query/in the browser, the forbidden appears:

Forbidden

You don't have permission to access/query on this server.

Additionally, a 403 Forbidden error is encountered while trying to use an errordocument to handle the request.

apache/2.0.52 (Red Hat) Server at localhost Port 80

For users who have just used Redhat Enterprise Linux4 or Fedora Core 2 or above/centos 4, the Apache will often not function properly, reported to "Permission denied" and other errors and greatly puzzled, even greatly annoyed.

In fact, this is due to the activation of selinux in these systems, and the user's Apache configuration and the SELinux configuration policy is generated, only through the appropriate adjustment, so that Apache configuration and access to comply with the policy to normal use.

Now let's analyze the context definition for httpd (Apache) in SELinux (slightly abridged).

/home/[^/]+/((WWW) | ( Web) | (public_html)) (/.+)? system_u:object_r:httpd_user_content_t

/var/www (/.*)? system_u:object_r:httpd_sys_content_t

/var/www/cgi-bin (/.*)? system_u:object_r:httpd_sys_script_exec_t

/usr/lib/cgi-bin (/.*)? system_u:object_r:httpd_sys_script_exec_t

/var/www/perl (/.*)? system_u:object_r:httpd_sys_script_exec_t

/var/www/icons (/.*)? system_u:object_r:httpd_sys_content_t

/VAR/CACHE/HTTPD (/.*)? system_u:object_r:httpd_cache_t

/etc/vhosts--system_u:object_r:httpd_config_t

/USR/SBIN/HTTPD--system_u:object_r:httpd_exec_t

/usr/sbin/apache (2)? --system_u:object_r:httpd_exec_t

/usr/sbin/suexec--system_u:object_r:httpd_suexec_exec_t

/VAR/LOG/HTTPD (/.*)? system_u:object_r:httpd_log_t

/var/log/apache (2)? (/.*)? system_u:object_r:httpd_log_t

/var/log/cgiwrap.log.*--system_u:object_r:httpd_log_t

/var/cache/ssl.*.sem--system_u:object_r:httpd_cache_t

/var/cache/mod_ssl (/.*)? system_u:object_r:httpd_cache_t

/var/run/apache (2)? pid.*--system_u:object_r:httpd_var_run_t

/VAR/LIB/HTTPD (/.*)? system_u:object_r:httpd_var_lib_t

/var/lib/php/session (/.*)? System_u:object_r:httpd_var_run_t

/etc/apache-ssl (2)? (/.*)? system_u:object_r:httpd_config_t

/usr/lib/apache-ssl (/.*)? --system_u:object_r:httpd_exec_t

/usr/sbin/apache-ssl (2)? --system_u:object_r:httpd_exec_t

/var/log/apache-ssl (2)? (/.*)? system_u:object_r:httpd_log_t

/var/run/apache-ssl (2)? pid.*--system_u:object_r:httpd_var_run_t

/var/run/gcache_port-s system_u:object_r:httpd_var_run_t

/var/lib/squirrelmail/prefs (/.*)? system_u:object_r:httpd_squirrelmail_t

/usr/bin/htsslpass--system_u:object_r:httpd_helper_exec_t

/usr/share/htdig (/.*)? system_u:object_r:httpd_sys_content_t

/var/lib/htdig (/.*)? system_u:object_r:httpd_sys_content_t

For the above-mentioned content, the following several common problems can be easily handled:

1.phpmyadmin does not work in a non-default/var/www/html directory

Usually similar situation is configured in the virtual host, Access/phpmyadmin, such as prompt 403 Access denied, the log also prompts permission denied, this is because phpMyAdmin prevent the directory and the file itself attribute does not meet the context requirements.

Assuming that phpMyAdmin is placed in the/web directory, then execute:

Chcon-r-T Httpd_user_content_t/web

Will make/web and all of its subdirectories/files, including phpMyAdmin files, get httpd_user_content_t properties, and if their traditional UNIX attributes are readable for httpd, then revisit them should be possible.

The virtual host under the 2./home directory is not functioning

Similar to question 1, however, according to the context definition above, the/home directory must be the user's $home/www or public_html or web directory is the httpd_user_content_t type. It is therefore advisable to place the content of the Web page in the user's $home/www or Web or public_html, and to ensure that its properties are httpd_user_content_t, using the following command to view:

Ls-z/home/abc/

DRWXR-XR-X ABC abc user_u:object_r:user_home_dir_t TMP

DRWXRWXR-X ABC abc user_u:object_r:httpd_user_content www

If not, you can use Chcon to step through the directory and file changes until you finally have access to:

Chcon-r-T Httpd_user_content_t/home/abc/web

Chcon-t USER_HOME_DIR_T/HOME/ABC

3.CGI program cannot run

If the CGI program in the/var/www/cgi-bin/can not be executed, encountered 403 or 500 error, you may check the properties of the CGI program, as defined in the SELinux contexts file,/var/www/cgi-bin/must be httpd_ The Sys_script_exec_t property. View through Ls-z, if not, change it with the following command:

Chcon-t httpd_sys_script_exec_t/var/www/cgi-bin/*.cgi

If it is the CGI in the virtual host, then refer to question 2 to make it normal to use normal functions, and then set the CGI file through the Chcon context for httpd_sys_script_exec_t can be.

4.setuid/gid program does not run

Early Sqwebmail and Qmailadmin, for example, require Setuid/gid support, but this will be severely limited under SELinux. The first approach is a more thorough approach to preserving the security of the system by:

Audit2allow-l-i/var/log/messages

Convert the information that SELinux denies to the appropriate policy allow directive, add these instructions to the corresponding configuration file in SELinux Policy's SRC, regenerate the policy and load. But it's relatively troublesome to do so.

Another method is the simplest, but will not protect Apache. First make sure that the SELinux type is targeted:

Cat/etc/selinux/config|grep Selinuxtype

Then, make Apache out of SELinux protection:

Setsebool-p Httpd_disable_trans 1

Then restart Apache:

/ETC/INIT.D/HTTPD restart

In this way, all Apache mandatory checks are invalidated, and the programs that require setuid/gid can be used normally. However, this introduces the risk of increasing the vulnerability, which is an urgent need to run the situation, this method is a minimum system security to minimize the lack of a final approach. It may not be a good way to cancel SELinux.

SELinux results in Apache 403 error resolution