Bug 984212

Summary: SELinux is preventing /usr/bin/python2.7 from 'read' accesses on the file /etc/passwd.
Product: [Fedora] Fedora Reporter: carletronicon
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: carletronicon, dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:24a37f544d4133b0a9245e6b71c24abd756d4a0c3d2a281e52482b9e7ed12d19
Fixed In Version: selinux-policy-3.11.1-103.fc18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 00:43:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description carletronicon 2013-07-13 16:55:19 UTC
Description of problem:
I'm attempting to just set up a basic cgi-bin directory in my user's home directory (using python as the scripting language).  I did the following steps:
1) Reconfigured apache to enable homedirs and enable ~/public_html/cgi-bin to be cgi enabled
2) Ran senlinux command to enable homedirs (setsebool -P httpd_enable_homedirs true)
3) Created python script (python.cgi) that just prints out CGI works
#!/usr/bin/python

print "Content-type: text/html"
print ""
print "CGI works"
4) Created perl script (perl.cgi) which does same
#!/usr/bin/python

print "Content-type: text/html"
print ""
print "CGI works"
5) chmoded both scripts to 755
6) Going to http://<my ip>/~gamer/cgi-bin/perl.cgi correctly returns "CGI works" in browser
7) Going to http://<my ip>/~gamer/cgi-bin/python.cgi returns Internal Server Error to browser; SELinux popup indicates python was trying to access /etc/passwd (presumably as part of the suexec process, except unclear why perl is allowed and not python)
8) Following the suggested approach (through audit2allow / semodule), going to http://<myip>/~gamer/cgi-bin/python.cgi does now return the expected text instead of a server error
SELinux is preventing /usr/bin/python2.7 from 'read' accesses on the file /etc/passwd.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that python2.7 should be allowed read access on the passwd file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep generate_voice. /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:httpd_user_script_t:s0
Target Context                system_u:object_r:passwd_file_t:s0
Target Objects                /etc/passwd [ file ]
Source                        generate_voice.
Source Path                   /usr/bin/python2.7
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           python-2.7.3-13.fc18.x86_64
Target RPM Packages           setup-2.8.57-1.fc18.noarch
Policy RPM                    selinux-policy-3.11.1-97.fc18.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.9.6-200.fc18.x86_64 #1 SMP Thu
                              Jun 13 18:56:55 UTC 2013 x86_64 x86_64
Alert Count                   4
First Seen                    2013-07-13 12:20:13 EDT
Last Seen                     2013-07-13 12:40:04 EDT
Local ID                      a0c39846-82f0-45af-a53e-518c2e6bed22

Raw Audit Messages
type=AVC msg=audit(1373733604.35:368): avc:  denied  { read } for  pid=2493 comm="python.cgi" name="passwd" dev="dm-2" ino=3148058 scontext=system_u:system_r:httpd_user_script_t:s0 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file


type=SYSCALL msg=audit(1373733604.35:368): arch=x86_64 syscall=open success=no exit=EACCES a0=7fe97069c6ca a1=80000 a2=1b6 a3=238 items=0 ppid=1944 pid=2493 auid=4294967295 uid=1004 gid=1004 euid=1004 suid=1004 fsuid=1004 egid=1004 sgid=1004 fsgid=1004 ses=4294967295 tty=(none) comm=python.cgi exe=/usr/bin/python2.7 subj=system_u:system_r:httpd_user_script_t:s0 key=(null)

Hash: generate_voice.,httpd_user_script_t,passwd_file_t,file,read

audit2allow

#============= httpd_user_script_t ==============
allow httpd_user_script_t passwd_file_t:file read;

audit2allow -R
require {
	type httpd_user_script_t;
}

#============= httpd_user_script_t ==============
auth_read_passwd(httpd_user_script_t)


Additional info:
reporter:       libreport-2.1.5
hashmarkername: setroubleshoot
kernel:         3.9.6-200.fc18.x86_64
type:           libreport

Comment 1 Daniel Walsh 2013-07-24 22:08:57 UTC
So apache worked but you saw this ugly avc?

Comment 2 carletronicon 2013-07-27 23:21:49 UTC
(In reply to Daniel Walsh from comment #1)
> So apache worked but you saw this ugly avc?

No.  Apache returned HTTP 500 (since the cgi failed to run since SELinux blocked it.)  Note that cgi script ran fine when I ran it as my own user (i.e. did python hello.cgi from the command line)

As mentioned, after doing the suggested action (i.e. the auditallow), things work fine (i.e. apache returns HTTP 200 aka the expected hello page)

Comment 3 Daniel Walsh 2013-07-29 18:13:50 UTC
Does your cgi script actually read /etc/passwd or run a getpw* type call?

Comment 4 carletronicon 2013-08-03 22:22:15 UTC
(In reply to Daniel Walsh from comment #3)
> Does your cgi script actually read /etc/passwd or run a getpw* type call?

Explicitly: no.  See bullet 3 for the complete source.

Implicitly: probably; I'm starting with the stock fedora apache config (as in I took the stock httpd.conf file and uncommented the bits to enable public_html, general cgi-bin, and cgi-bin for users.)  This uses suexec (I thought) or some other semi-magic so that when I access http://127.0.0.1/~user/cgi-bin/hello.cgi, the hello.cgi runs as user instead of apache.  (And this was verified by printing out os.getuid() and os.geteuid() and verifying that they're both the uid of <user> instead of apache etc. )

Comment 5 Daniel Walsh 2013-08-05 16:48:42 UTC
Ok I guess we need to allow this.

Comment 6 Daniel Walsh 2013-08-05 16:58:43 UTC
136ec9ca404c359b7e158a921a252f11017fa4bc allows this in git.

Comment 7 Miroslav Grepl 2013-08-07 14:29:45 UTC
Back ported.

Comment 8 Fedora Update System 2013-09-02 15:27:59 UTC
selinux-policy-3.11.1-101.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-101.fc18

Comment 9 Fedora Update System 2013-09-02 23:26:41 UTC
Package selinux-policy-3.11.1-101.fc18:
* should fix your issue,
* was pushed to the Fedora 18 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.11.1-101.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-15645/selinux-policy-3.11.1-101.fc18
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2013-09-10 11:16:49 UTC
selinux-policy-3.11.1-103.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/selinux-policy-3.11.1-103.fc18

Comment 11 Fedora Update System 2013-09-23 00:43:50 UTC
selinux-policy-3.11.1-103.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.