here is a diff between my apache systems (#48774) and sec-policy/selinux-apache-20040426 can you please consider including these changes in the policy? ---- c u t h e r e ------------------- # apache.fc /var/cache/apache-mm(/.*)? system_u:object_r:httpd_cache_t # apache.te # manage files in /var/log/httpd/* allow httpd_t httpd_log_t:dir create_dir_perms; allow httpd_t httpd_log_t:file create_file_perms; # connect to mysql ifdef(`mysqld.te', ` can_unix_connect(httpd_t, mysqld_t) allow httpd_t var_lib_t:dir { search }; allow httpd_t mysqld_var_run_t:dir { search }; allow httpd_t mysqld_var_run_t:sock_file { write }; ') ---- c u t h e r e ------------------- I have replaced httpd_php_t with httpd_t because there is no file labeled http_php_exec_t and there is no patch to mod_php that would make a domain transition to http_php_t. tested for a few days with apache 1.3.x, vanilla 2.6.7
The /var/cache/apache-mm .fc entry seems fine, but why is the /var/log/apache policy needed? I'll have the check about the php stuff.
fc change in selinux-apache-20040704. The other two changes seem more like ones needed for your setup, and not appropriate for general use. While there arent any http_php_exec_t in the fc of the policy, ones need to be added for your config.
allow httpd_t httpd_log_t:dir { remove_name }; allow httpd_t httpd_log_t:file { setattr unlink }; audit(1089101734.274:0): avc: denied { remove_name } for pid=1314 exe=/usr/sbin/apache name=ssl_scache.sem dev=sda6 ino=176490 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:httpd_log_t tclass=dir audit(1089101734.274:0): avc: denied { unlink } for pid=1314 exe=/usr/sbin/apache name=ssl_scache.sem dev=sda6 ino=176490 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:httpd_log_t tclass=file audit(1089101735.841:0): avc: denied { setattr } for pid=4763 exe=/usr/sbin/apache name=ssl_scache.sem dev=sda6 ino=176490 scontext=system_u:system_r:httpd_t tcontext=system_u:object_r:httpd_log_t tclass=file is needed when apache recreates /var/log/apache/ssl_scache.sem on every restart. a log_domain() would have been much better, but I guess that my 2 lines would be much less intrusive. and for that http_php_t, I fail to find how can a process transition to that domain without a patch to mod_php (that doens't exist as far as I know). I guess that the policy was made for a system that uses the php CLI (highly bad idea) instead of mod_php. those ifdef(mysql.te) lines are used on all systems that have non-static pages based on mysql.
I can't allow apache to delete its log files because of the poor default placement of that file. The better choice would be to move the file to a directory in /var/cache. It looks like the option SSLSessionCache is what you want to change. As for the php, I don't know; I don't use fancy stuff like that on my server :)
good point with the 'SSLSessionCache' option. but in this case, can you please also add /var/cache/apache(/.*)? system_u:object_r:httpd_cache_t so that file_auto_trans's work I'll add the mysql stuff to the ever-growing my.te ;)
PHP related problems are probably from running mod_php rather than a cgi php. if you are using mod_php then php scripts are read and executed by the apache binary and therefore in the httpd_t domain, there will never be a transition to httpd_php_t with mod_php, it is not possible. With the cgi version of php (emerge php-cgi) you can use the php domain by setting the file context of php-cgi to system_u:object_r:httpd_php_exec_t and then setting up apache to spawn the php cgi process (you'll likely need to remove mod_php to do this correctly).. you should see something like this if you've done it correctly 11488 system_u:system_r:httpd_t /usr/sbin/apache2 -k start -D SSL 11490 system_u:system_r:httpd_php_t /usr/bin/php-cgi now they are running in different domains ;)
method: what you say is true, and I would not like to start a mod_php vs phpcgi thread. the question is: should we simply ignore the smart people that use mod_php and selinux? :)
most of it is in CVS. the rest will come after a nsa policy merge.
