Red Hat Bugzilla – Bug 479023
selinux won't let me run cgi scripts in my home directory
Last modified: 2009-03-03 14:47:31 EST
Description of problem: I had a machine setup as a web server that allowed me to run cgi scripts out of my home directory. I migrated to a new machine (using rsync) and now selinux complains about everything to do with access to my personal web page. After running restorecon -v '.' and "setsebool -P httpd_enable_homedirs 1", I was able to read static content again but cgi scripts are verboten! setroubleshoot actually recommends I file a bug!! So here it is. Version-Release number of selected component (if applicable): selinux-policy-3.5.13-34.fc10 How reproducible: always Steps to Reproduce: 1. get a personal web server running 2. rsync it to another machine 3. try to access the new machine Actual results: Verboten! Expected results: Permitted Additional info: Here is the output of setroubleshoot Summary SELinux is preventing suexec (httpd_suexec_t) "execute" to ./patch.cgi (httpd_user_content_t). Detailed Description SELinux denied access requested by suexec. It is not expected that this access is required by suexec and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./patch.cgi, restorecon -v './patch.cgi' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional Information Source Context: system_u:system_r:httpd_suexec_t:s0 Target Context: system_u:object_r:httpd_user_content_t:s0 Target Objects: ./patch.cgi [ file ]Source: suexec Source Path: /usr/sbin/suexec Port: <Unknown> Host: grinch Source RPM Packages: httpd-2.2.10-2 Target RPM Packages: Policy RPM: selinux-policy-3.5.13-34.fc10 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: EnforcingPlugin Name: catchall_file Host Name: grinch Platform: Linux grinch 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 Alert Count: 3 First Seen: Tue 06 Jan 2009 10:30:22 AM EST Last Seen: Tue 06 Jan 2009 10:35:59 AM EST Local ID: 8e8d3c4b-fd80-4664-9f1a-3c8915f0736c Line Numbers: Raw Audit Messages : node=grinch type=AVC msg=audit(1231256159.80:1537): avc: denied { execute } for pid=26871 comm="suexec" name="patch.cgi" dev=dm-1 ino=361982 scontext=system_u:system_r:httpd_suexec_t:s0 tcontext=system_u:object_r:httpd_user_content_t:s0 tclass=file node=grinch type=SYSCALL msg=audit(1231256159.80:1537): arch=c000003e syscall=59 success=no exit=-13 a0=7fff5f334b55 a1=7fff5f333c40 a2=7fe4590d6010 a3=7fff5f331530 items=0 ppid=2211 pid=26871 auid=4294967295 uid=10328 gid=10328 euid=10328 suid=10328 fsuid=10328 egid=10328 sgid=10328 fsgid=10328 tty=(none) ses=4294967295 comm="suexec" exe="/usr/sbin/suexec" subj=system_u:system_r:httpd_suexec_t:s0 key=(null)
Don, this problem relates with your location and labeling of cgi scripts. There are some options, how to fix it. 1.You can change context of scripts and turn on the httpd_enable_cgi boolean: # chcon -t httpd_user_script_exec_t *.cgi # setsebool -P httpd_enable_cgi 1 2. You can move scripts to the proper location for cgi scripts and run restorecon. Examples of locations: /var/www/cgi-bin(/.*)? /var/www/[^/]*/cgi-bin(/.*)? /var/www/perl(/.*)? /var/www/html/[^/]*/cgi-bin(/.*)? If you want to run cgi scripts from your home directory with the present context, you should activate this booleans: # setsebool -P httpd_enable_cgi 1 # setsebool -P httpd_unified 1 But the last option evokes it, that http don't differentiate file controls based on context.
Well, # setsebool -P httpd_enable_cgi 1 # setsebool -P httpd_unified 1 seemed to have worked. My original box didn't have to do any of this stuff. It was running fedora 9. I spent days trying to figure out how to configure httpd to run cgi scripts from my home directory. Now after copying everything over to my new box, I have to run all these selinux checks? How do I know nothing else was broken on my move over to my new box? Just seems silly all these selinux policy things. Can't it figure out from the httpd that I configured it to allow user home directories to run cgi scripts? Anyway, thanks for the help. -Don
If you were running setroubleshoot it should have told you to try some of those things. There is a fine line between SELinux knowing that httpd is trying to read/execute content in the home direcory and an attacker, breaking into apache and trying to access stuff in your home directory.
I think I did run setroubleshoot (is that the program with the sheriff's badge?) and it suggested "restorecon -v '.'" and "setsebool -P httpd_enable_homedirs 1" for me. Which got me past my intial problems. But that didn't work for the cgi stuff. The setroubleshoot message for my cgi scripts was 'file a bug'. So that's what I did. :-) -Don
Ok this fooled setroubleshoot because you had to have two boolean set to allow it. setroubleshoot takes the default policy and then tries to set the booleans one by one to see if the policy would allow it, but in this case it needed to set two booleans to allow. Which would make this a factorial problem and would take a huge about of time and cpu to test all possible combinations.
Alright, these policies are really making me grumpy. I touched .autorelabel because of other selinux problems and rebooted. Now selinux policy just makes me chase my tail by setting some http context, then restoring it with restorecon, then making me set http context again. !!!How can I make my web server with cgi scripts that create/remove temp files work correctly without throwing the sheriffs badge at me!!! I tried setting these setsebool -P httpd_unified=1 setsebool -P httpd_enable_cgi 1 but they don't seem to work correctly. Otherwise I am just going to give up and turn selinux off and consider it broken. Sorry for the rant, it is just frustrating to waste an hour trying to get this working so I can go back to developing again.
Created attachment 329259 [details] latest output of everything
Don, could you execute restorecon -F -r -v ~/public_html These should be labeled httpd_user_content_t not httpd_sys_content_t Did you intentionally label files in your home dir as public_content_t? Do you want to share this content with other confined domains like ftp?
Created attachment 329395 [details] Patch to allow httpd_user_script_t access to homedir content Miroslav can you add this patch to F10 policy
Dan, I executed the command and received some new warnings. I'll attach those, but basically they were saying run 'setsebool -P httpd_unified=1' which I must have run a half a dozen times over the last week or so. As for labeling, public_content_t, if it was labeled that way it was because setroubleshoot told me too. I am not sure what you mean by other confined domains like ftp. -Don
Created attachment 329397 [details] latest output
Miroslav you also need to add tunable_policy(`httpd_enable_cgi && httpd_unified',` allow httpd_user_script_t httpdcontent:file entrypoint; manage_dirs_pattern(httpd_user_script_t, httpd_user_content_t, httpd_user_content_t) manage_files_pattern(httpd_user_script_t, httpd_user_content_t, httpd_user_content_t) manage_files_pattern(httpd_user_script_t, httpd_user_script_ra_t, httpd_user_script_ra_t) ') Don you can modify your local policy by executing # grep avc /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp
Dan, That seemed to do the trick thanks! -Don
Fixed in selinux-policy-3.5.13-40.fc10.noarch
Created attachment 331703 [details] selinux-troubleshoot output So I had all this stuff working before. Then I decided to yum update my box and reboot. It seems all the stuff I had working before disappeared. Any reason why all the changes didn't stick across a reboot?
I think this is a different avc then the ones you got before. It is talking about "entrypoint" httpd_user_content_t is not allowed as an entrypoint for the httpd_sys_script_t domain. Which means httpd_suexec_t is not allowed to transition on this type of file. If you labeled chcon -R -t httpd_sys_script_exec_t /home/dzickus/public_html/patches/cgi-bin THis would fix the problem.
Miroslav, we need this line added to policy allow httpd_sys_script_t httpdcontent:file entrypoint;
Ok. Thanks for the command. It seem to have worked. Unfortunately, I am not at my desk to see if the sheriff's badge went off. But remotely accessing my website seems to work. Thanks.
Fixed in selinux-policy-3.5.13-46.fc10
Everything is broken again. I was trying to run another http server and because it didn't like how I set everything up in /work, selinux wanted me to 'touch /.autorelabel' to label the /work directory correctly. Well upon reboot and relabeling that screwed up my original settings for my other webserver. " If you want to change the file context of /home/dzickus/public_html/patches/cgi-bin/patch.cgi so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t '/home/dzickus/public_html/patches/cgi-bin/patch.cgi'. You can look at the httpd_selinux man page for additional information. " Is there any way to tell selinux there is a webserver under foo/, bar/, and foobar/ without all this relabeling and repeated previous commands? I feel like I have to ask permission to do anything on my own box. /me understands the pains of Vista users..
# semanage fcontext -a -t httpd_sys_content_t '/work(/.*)?' # semanage fcontext -a -t httpd_sys_script_exec_t '/home/dzickus/public_html/patches/cgi-bin(/.*)?' restorecon -R -v /work /home/dzichus/public_html Should fix it permanently.
Cool, everything works again. Thanks