Bug 134990 - python CGI script fails with selinux enabled when accessing a symlink in document root
python CGI script fails with selinux enabled when accessing a symlink in docu...
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2004-10-07 15:26 EDT by James Laska
Modified: 2013-09-02 02:01 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-18 16:15:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
src/policy/domains/misc/later.te (1.52 KB, text/plain)
2004-10-07 15:45 EDT, James Laska
no flags Details

  None (edit)
Description James Laska 2004-10-07 15:26:24 EDT
# TREE rawhide-20041007
# ARCH i386

I have httpd serving up public_html/ for a local user.  That user has
FollowSymlinks turned on in httpd.conf.  I am running a CGI web tool
written in python that attempts to access the symlink.  With selinux
enabled the CGI fails in what boils to to EPERMDENIED.

raceback (most recent call last):
  File "index.cgi", line 12, in ?
  File "/home/jlaska/public_html/TemplateClass.py", line 141, in display
    print self.header()
  File "/home/jlaska/public_html/TemplateClass.py", line 118, in header
    return Template( file=tmplfile, searchList= [self.vars] )
  File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line
156, in __init__
    self.compile(source, file)
  File "/usr/lib/python2.3/site-packages/Cheetah/Template.py", line
235, in compile
    self._fileMtime = os.path.getmtime(file)
line 146, in getmtime
    return os.stat(filename).st_mtime
OSError: [Errno 13] Permission denied:

The file that is getting the permission denial above is accessable by
python when run outside of apache (from a shell).  The file is a
symlink that points to another file within the users public_html/

(~/public_html)> ls -Z templates/default/header.tmpl
-rw-r--r--  jlaska   jlaska   system_u:object_r:httpd_user_content_t
(jlaska@flatline)-(3/pts/5)-(10/07/2004 03:23pm)-
(~/public_html)> ls -Z templates/redhat.com/header.tmpl
lrwxrwxrwx  jlaska   jlaska   user_u:object_r:httpd_sys_content_t
templates/redhat.com/header.tmpl -> ../default/header.tmpl

The interesting thing is that when I point my web browser to the
symlink directly...it loads fine.  However, when I point the web
browser to the cgi script that loads the symlink, it fails with
selinux denial messages:

Oct  7 13:42:06 flatline kernel: audit(1097170926.811:0): avc:  denied
 { read } for  pid=13875 exe=/usr/bin/python name=header.tmpl dev=hda2
ino=272895 scontext=root:system_r:httpd_suexec_t
tcontext=user_u:object_r:httpd_sys_content_t tclass=lnk_file
Oct  7 13:42:06 flatline kernel: audit(1097170926.946:0): avc:  denied
 { search } for  pid=13875 exe=/usr/bin/python name=src dev=hda3
ino=1788293 scontext=root:system_r:httpd_suexec_t
tcontext=system_u:object_r:src_t tclass=dir

It was able to resolve the denials by appending the following rules to
domains/misc/later.te :

allow httpd_suexec_t httpd_sys_content_t:lnk_file { read };
allow httpd_suexec_t src_t:dir { search };

It also appears I'm able to get by with only the first rule:

allow httpd_suexec_t httpd_sys_content_t:lnk_file { read };
Comment 1 Colin Walters 2004-10-07 15:35:50 EDT
Wait...are you running in permissive mode?  How do you have a CGI
script running as httpd_suexec_t??  That's very wrong, only
/usr/sbin/suexec should be running in that domain.
Comment 2 Colin Walters 2004-10-07 15:36:58 EDT
What is the label on the CGI script?  Can you do:

ls -adZ /path/to/your/script.cgi
Comment 3 James Laska 2004-10-07 15:45:51 EDT
Created attachment 104911 [details]

I have other rules in my later.te that were suggested to get me to a point were
I could use selinux and this CGI.

(~)> ls -adZ public_html/index.cgi
-rwxr-xr-x  jlaska   jlaska   system_u:object_r:httpd_user_content_t
Comment 4 Colin Walters 2004-10-07 15:55:33 EDT
allow httpd_suexec_t file_t:file { create execute execute_no_trans
getattr ioctl read unlink write };
allow httpd_suexec_t httpd_sys_content_t:file { execute
execute_no_trans getattr ioctl read };

These rules ccompromise the security of httpd_suexec_t; it should only
be allowed to execute specifically labeled files.

In this case, the correct fix is to change the label on your CGI
script to allow httpd_suexec_t to execute it:

chcon -t httpd_sys_script_exec_t ~jlaska/public_html/index.cgi

Many other rules in your later.te are symptoms of other problems as
well.  Can you try starting over without later.te and seeing whether
relabeling the CGI script allows the desired access?

Incidentally I'd suggest putting system CGI scripts somewhere under
/var/www, and only allowing user CGI scripts like ~jlaska/public_html
to be httpd_user_script_exec_t.

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