SELinux致使Apache 403錯誤解決方法

將DocumentRoot設在/var/www/html下能夠訪問

可是將DocumentRoot設在其餘目錄（如：/webroot）下就出現Forbidden了。在./etc/httpd/conf/httpd.conf中的相關部分是這樣的：

Alias /query "/home/query"

<Directory "/home/query">

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

可是在瀏覽器中輸入：http://localhost/query/ 時，出現Forbidden：

Forbidden

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

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

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

對於剛使用Redhat Enterprise Linux4 或Fedora Core 2以上/CentOS 4的用戶，必定會爲Apache常常沒法正常運轉，報以"Permission denied"等錯誤而大爲不解，甚至大爲惱火。

其實這是由於這些系統裏激活了SELinux，而用戶的apache配置與SELinux的配置策略有抵觸產生的，只有經過適當調整，使apache的配置和訪問符合策略才能正常使用。

如今下面來分析一下SELinux中有關httpd（apache）的context定義（略有刪節）

/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

針對上述的內容，能夠對以下的幾個常見問題進行簡單處理：

1.phpmyadmin在非默認/var/www/html目錄下沒法運轉

一般相似的狀況都是在配置了虛擬主機時，訪問/phpmyadmin等提示403訪問拒絕，日誌裏也提示Permission denied，這是由於phpmyadmin防止的目錄及文件自己屬性不符合context要求。

假設phpmyadmin放在/web目錄下，那麼執行:

chcon -R -t httpd_user_content_t /web

則會令/web及其下全部子目錄/文件，包括phpmyadmin文件都得到了httpd_user_content_t的屬性，若是其傳統的Unix屬性對httpd來講是可讀的話，再從新訪問一下就應該能夠了。

2./home目錄下的虛擬主機沒法運轉

與問題1也是相似的，不過根據上文中context的定義，/home目錄下必須是用戶的$HOME/www或public_html或web目錄纔是 httpd_user_content_t類型，所以建議將要做爲web頁面的內容放置在用戶的$HOME/www或web或public_html裏，並確保其屬性是httpd_user_content_t，使用以下命令查看：

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

如不是，則可經過chcon來逐級目錄及文件更改，直至最後能訪問：

chcon -R -t httpd_user_content_t /home/abc/web

chcon -t user_home_dir_t /home/abc

3.CGI程序沒法運行

若是cgi程序放在/var/www/cgi-bin/裏也沒法執行，遇到403或500錯誤的話，能夠檢查cgi 程序的屬性，按SELinux contexts文件裏定義的，/var/www/cgi-bin/裏必須是httpd_sys_script_exec_t 屬性。經過ls -Z查看，若是不是則經過以下命令更改：

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

若是是虛擬主機裏的cgi，則參考問題2使之能正常使用普通的功能後，再經過chcon設置cgi文件的context爲httpd_sys_script_exec_t便可。

4.Setuid/gid 程序沒法運行

例如早期的SqWebMail及qmailadmin等，須要setuid/gid的支持，但在SELinux下這將受到嚴格限制。第一種方法是比較完全的辦法，能保留系統的安全性，經過：

audit2allow -l -i /var/log/messages

將SELinux拒絕的信息轉換爲相應的policy allow指令，將這些指令添加到SELinux policy 的src裏相應的配置文件，從新生成policy並加載。但這樣作相對比較麻煩。

另外一個方法最簡單，但將使apache得不到保護。首先肯定SELinux 類型是targeted的：

cat /etc/selinux/config|grep SELINUXTYPE

而後，使apache脫離SELinux保護：

setsebool -P httpd_disable_trans 1

而後重啓動apache：

/etc/init.d/httpd restart

這樣全部apache強制的檢查都失效，須要setuid/gid的程序能夠正常使用。但這樣帶來了增長漏洞的危險，對於迫切須要運行而又很急的狀況，本方法是一個最大限度減小系統安全缺失的最後辦法。對於取消SELinux 未必是一個好方法。