Bug 479023

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