Bug 479023 - selinux won't let me run cgi scripts in my home directory
selinux won't let me run cgi scripts in my home directory
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-06 10:49 EST by Don Zickus
Modified: 2009-03-03 14:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-03 14:47:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
latest output of everything (22.32 KB, application/octet-stream)
2009-01-16 17:21 EST, Don Zickus
no flags Details
Patch to allow httpd_user_script_t access to homedir content (1.32 KB, application/octet-stream)
2009-01-19 15:14 EST, Daniel Walsh
no flags Details
latest output (9.76 KB, application/octet-stream)
2009-01-19 15:29 EST, Don Zickus
no flags Details
selinux-troubleshoot output (2.91 KB, text/plain)
2009-02-12 10:43 EST, Don Zickus
no flags Details

  None (edit)
Description Don Zickus 2009-01-06 10:49:54 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)
Comment 1 Miroslav Grepl 2009-01-07 07:44:28 EST
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.
Comment 2 Don Zickus 2009-01-07 10:38:40 EST
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
Comment 3 Daniel Walsh 2009-01-07 12:50:28 EST
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.
Comment 4 Don Zickus 2009-01-07 13:13:45 EST
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
Comment 5 Daniel Walsh 2009-01-07 15:29:20 EST
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.
Comment 6 Don Zickus 2009-01-16 17:20:20 EST
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.
Comment 7 Don Zickus 2009-01-16 17:21:01 EST
Created attachment 329259 [details]
latest output of everything
Comment 8 Daniel Walsh 2009-01-19 15:13:29 EST
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?
Comment 9 Daniel Walsh 2009-01-19 15:14:24 EST
Created attachment 329395 [details]
Patch to allow httpd_user_script_t access to homedir content

Miroslav can you add this patch to F10 policy
Comment 10 Don Zickus 2009-01-19 15:27:58 EST
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
Comment 11 Don Zickus 2009-01-19 15:29:09 EST
Created attachment 329397 [details]
latest output
Comment 12 Daniel Walsh 2009-01-19 15:39:34 EST
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
Comment 13 Don Zickus 2009-01-19 16:30:13 EST
Dan,

That seemed to do the trick thanks!

-Don
Comment 14 Miroslav Grepl 2009-01-20 14:04:02 EST
Fixed in selinux-policy-3.5.13-40.fc10.noarch
Comment 15 Don Zickus 2009-02-12 10:43:38 EST
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?
Comment 16 Daniel Walsh 2009-02-13 08:40:10 EST
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.
Comment 17 Daniel Walsh 2009-02-13 08:44:33 EST
Miroslav, we need this line added to policy

allow httpd_sys_script_t httpdcontent:file entrypoint;
Comment 18 Don Zickus 2009-02-13 09:12:31 EST
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.
Comment 19 Miroslav Grepl 2009-02-19 11:25:12 EST
Fixed in selinux-policy-3.5.13-46.fc10
Comment 20 Don Zickus 2009-03-03 11:17:21 EST
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..
Comment 21 Daniel Walsh 2009-03-03 11:32:13 EST
# 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.
Comment 22 Don Zickus 2009-03-03 12:00:18 EST
Cool, everything works again.  Thanks

Note You need to log in before you can comment on or make changes to this bug.