cat > mywebapp.te << EOF policy_module(mywebappp, 1.0.0) apache_content_template(mywebapp) EOF make -f /usr/share/selinux/devel/Makefile mywebapp.pp sudo semodule -i mywebapp Now you can use the following new types: httpd_mywebapp_script_t (mywebapp process type) httpd_mywebapp_script_exec_t (mywebapp cgi executable file type) httpd_mywebapp_content_t (mywebapp readonly file type) httpd_mywebapp_content_rw_t (mywebapp read/write file type) httpd_mywebapp_content_ra_t (mywebapp read/append file type) httpd_mywebapp_htaccess_t (mywebapp htaccess file types) Basically you can just label the cgi script with the mywebapp script executable file type and then the mywebapp process will run with the mywebapp process type creating files with the mywebapp content file types.
This solution satisfies "1", changing both the process label and the target label. This is probably the best solution, since if Richard used other CGI scripts on his machine, only the mapserver cgi script would be able to write the mapserver cgi content, and he would have better separation.
Note: I would have used sepolicy generate --cgi PATHTO/mapserver.cgi to generate the policy.
Could I modify the SELinux configuration to allow this access?
A third option would be to turn on the httpd_unified boolean. (This would an option of type "2"). Although not the best solution for the problem.
httpd_unified is described as "Unify HTTPD handling of all content files."
# setsebool -P httpd_unified 1
This means it will allow the apache process and default apache scripts to read/write/execute all default labeled apache content.
Bottom line, when you see an SELinux AVC, the way your decision tree should go something like the following.
Currently Tools like NSS (Mozilla products like Firefox/Thunderbird), GnuTLS, OpenSSL and Java on a Fedora box ship their own public key certificates and their own trust relationships. This means if an administrator wants to add/modify/delete trust to certain Certificates, he might have to modify several different stores in order to get the correct security.
A new feature in Fedora 19 is a system wide trust store of static data to be used by crypto toolkits as input for certificate trust decisions.
This feature the tools listed above a default source for retrieving system certificate anchors and black list information. Fedora 19 will be the first step toward development of a comprehensive solution.
Look at the feature for more information on the changes, but the following two sections explain the key benefits to this feature and how users will use it.
The goal is to empower administrators to configure additional trusted CAs, or to override the trust settings of CAs, on a system wide level, as required by local system environments or corporate deployments. Although this is theoretically possible today, it's extremely hard to get right.
Fedora will immediately gain a unified approach to system anchor certificates and black lists. This is then built on in the future to be a comprehensive solution.
Administrators will be able to use a tool to add a certificate authority file to the system trust store and have it recognized by all relevant applications.
Users will stop being surprised by incoherent and unpredictable trust decisions when using different applications with websites/services which require custom trust policy.