Bug 448445

Created attachment 306712 [details]
Policy to allow execmem for CGI scripts

I also notice that SELinux prevents tmpwatch (tmpreaper_t) "getattr" to
/tmp/cgiapp.pid (httpd_sys_content_rw_t). The file /tmp/cgiapp.pid is a lock
file created by a CGI script that ensures at most one copy of the big CGI
program is running at any time.  The program tmpwatch was trying to reap a lock
file left over after a crash.

I think allowing httpd_sys_script_t execmem calls for special policy, Either
write a wrapper for your cgi or load a custom policy to allow all scripts to
execmem.

How did a httpd_sys_content_rw_t file get on /tmp?  Looks like it was moved there.
Need to either fix the label using chcon or remove it.  

Created attachment 310931 [details]
Script that creates /tmp file entry with type httpd_sys_content_rw_t

Thanks Dan.  I'm ahead of you on the custom policy.  The last release of my
application included the custom policy attached to this bug report.

The httpd_sys_content_rw_t file was created in /tmp by the CGI script.  It's a
lock file used to make only one copy of the program is running at a time.  The
SELinux policy determined the label.  I've enclosed the shell script that wraps
the a Python script that wraps the Haskell program.  The shell script enforces
the one-at-a-time rule.

My point was to create a haskell cgi script versus just adding a boolean to
httpd_sys_script_t.  Your method will allow all cgi scripts execmem, while if
you created httpd_haskell_script_t you would only allow it to scripts labeled
httpd_haskell_script_exec_t

Current policy has roles to allow tmpreaper to delete these files

 sesearch --allow | grep tmpreaper | grep http
WARNING: This policy contained disabled aliases; they have been removed.
   allow tmpreaper_t httpd_sys_content_rw_t : file { getattr unlink }; 
   allow tmpreaper_t httpd_sys_content_rw_t : dir { ioctl write getattr lock
remove_name search rmdir }; 
   allow tmpreaper_t httpd_sys_content_rw_t : lnk_file { getattr unlink }; 
   allow tmpreaper_t httpd_sys_content_rw_t : sock_file { getattr unlink }; 
   allow tmpreaper_t httpd_sys_content_rw_t : fifo_file { getattr unlink }; 

Your right.  Your version of the policy is superior to mine.  My desktop machine
is within my company's firewalls, so I normally run Fedora on my desktop in
permissive mode.  I now have cause to use enforcing mode for a project unrelated
to the one using the web server.  The goal of the policy I wrote was to quickly
enable work on the other project while preserving the desktop's ability to run
my CGI scripts.  I was not guided by the principle of least privilege.

I found a reward when running in permissive mode without my policy module
loaded.  Whenever my CGI script runs, setroubleshoot alerts me to this fact.  I
learned to appreciate and use the realtime reports sent to me using an easy to
use mechanism that required no setup.  Since I can usually guess who's using the
server, I know when to appear in that person's office, and be sure my program
will be a good topic for discussion. These timely discussions have led to
several improvements in the program.  I bet this is a way of using
setroubleshoot no one thought of beforehand!