Bug 733545

Is this CGI script your own or is this something what Fedora ships?

Very much mine. I wasn't sure whether this deserved a bug, but when I asked on #selinux, dgrift suggested it was, so here we are.

Like I said, I can't think of a reason to limit these reads at all, to anyone, ever; can you?

-Robin

I agree allow it.

miscfiles_read_tetex_data(httpd_t)

Ok, I was just interested about path to CGI script and adding label for it.

This does not look like it is using a cgi.


It would be scontext=httpd_sys_script_t if it was cgi,

It is httpd_t so it is running within the apache process.

Indeed this is mod_perl. It just reads the web content and executes it as httpd_t.

But it does not really matter, one could have just as easily written this using php, still should work though.

(In reply to comment #4)
> Ok, I was just interested about path to CGI script and adding label for it.

I thought about that as well, but after digging a bit i came to the following conclusion.

So i thought, well you may be able to run CGI scripts in the httpd_t domain if you:

1. have httpd_unified set to on.
2. and you have your CGI script labelled with a type that is normally not executable by httpd_t (example: httpd_sys_content_t)

httpd_t would have been able to execute it but it would not have been allowed to execute_no_trans. (seems PHP works like libs, where httpd_t needs to mmap (execute) the php file only. Not actually "execute" it (e.g. execute and execute_no_trans))

So with that in mind, i guess one can never run CGI in the httpd_t domain.

I have the following python CGI script

#cat iamcgi.py 
#!/usr/bin/python

print 'Content-type: text/plain; Charset="iso-8859-2"'
print '' 
print 'I am Python CGI script'

import os, sys, commands

rc, output = commands.getstatusoutput("cat /tmp/test1")

if rc == 0:
	print(output)


# ls -lZ iamcgi.py 
-rwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 iamcgi.py

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t auditd_log_t:file read;



# chcon -t bin_t iamcgi.py
# ls -Z iamcgi.py 
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       iamcgi.py

#============= httpd_t ==============
allow httpd_t auditd_log_t:file read;

yes bin_t is the exception to the rule (obviously)

I was talking about httpd types.

I think we used to have a transition on bin_t to httpd_sys_script_t.  Might
have caused problems, I guess.

So I guess setting pdflatex to httpd_sys_script_exec_t would be a good
solution.

yeap, i just wanted to show my reason why i wanted to see path and context

(In reply to comment #12)
> yeap, i just wanted to show my reason why i wanted to see path and context

You are right. Good point.

(In reply to comment #11)
> I think we used to have a transition on bin_t to httpd_sys_script_t.  Might
> have caused problems, I guess.
> 
> So I guess setting pdflatex to httpd_sys_script_exec_t would be a good
> solution.

I think currently you might get into entry point issues, if for example userdomains run it. httpd_sys_script_exec_t is only an entry point to httpd_sys_script_t currently.

miscfiles_read_tetex_data(httpd_t) is not such a bad solution.

selinux-policy-3.9.16-39.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-39.fc15

Package selinux-policy-3.9.16-39.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.9.16-39.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-39.fc15
then log in and leave karma (feedback).

selinux-policy-3.9.16-39.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.