Bug 509943
Summary: | Have to change home directory to httpd_user_content_t when SELinux is enforcing | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Toshio Ernie Kuratomi <a.badger> | ||||||||
Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> | ||||||||
Status: | CLOSED WONTFIX | QA Contact: | Ben Levenson <benl> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 11 | CC: | johnp, lmacken | ||||||||
Target Milestone: | --- | Keywords: | Reopened | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2010-06-28 13:30:17 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: | |||||||||||
Attachments: |
|
Description
Toshio Ernie Kuratomi
2009-07-07 02:43:47 UTC
You need to label the directory in your homedir with httpd_user_content_t or httpd_sys_content_t, then it should work. public_html for example matchpathcon /home/devel/dwalsh/public_html/ /home/devel/dwalsh/public_html unconfined_u:object_r:httpd_user_content_t:s0 THen the boolean should work. The relabeling does not happen automatically, you need to do this. The boolean just allows httpd_t to search through the homedir for files labeled as httpd_*_t files. So if you chcon -R -t httpd_user_content_t /home/badger/pkgdb It should work. It doesn't work. The script that's being accessed is /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi Here's what I presently have: drwxr-xr-x. badger badger unconfined_u:object_r:user_home_t:s0 /home/badger drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 pkgdb drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 sqlalchemy -rwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on I'll attach the audit.log that's generated by just restarting httpd (no messages) and trying to hit the URL served by the script, https://localhost/pkgdb/ Created attachment 351296 [details]
audit.log
audit.log taken after truncating, then restarting httpd (no messages), then trying to hit the URL hit by the script.
Correction, the first time I did this, setroubleshoot told me that I didn't have the default labelling for /home/badger so I relabelled just /home/badger via restorecon. The label on /home/badger for this audit.log was:: drwxr-xr-x. badger badger unconfined_u:object_r:user_home_dir_t:s0 badger FWIW, the previous run with user_home_t:s0 seemed to have the same AVCs. Toshio you need to put the application in a subdir of your homedir, to get the labeling to work correctly. httpd_t is allowed to read/use directories labeled httpd_user_content_t as subdirs of /home/badger not directly there. The AVC's you attached shows httpd trying to search around in the /home/badger directory, even searching the .local directory Can't you put your app in public_html/ directrory? Toshio do you want to share your entire home directory via httpd? If so you will have to add a custom policy for this. The goal of the boolean is to allow the user to share just certain directories in the homedir not the entire directory. Directories like ~/public_html Create a file called myapache.te ============================== cut ====================================== policy_module(myapache, 1.0) gen_require(` attribute user_home_type; type httpd_t; ') list_dirs_pattern(httpd_t, user_home_type, user_home_type) read_files_pattern(httpd_t, user_home_type, user_home_type) ========================================================================== # make -f /usr/share/selinux/devel/Makefile # semodule -i myapache.pp (In reply to comment #5) > Toshio you need to put the application in a subdir of your homedir, to get the > labeling to work correctly. > Do you mean a direct subdirectory of homedir? I have it in a subdirectory of a subdirectory of homedir right now:: /home/badger/pkgdb/sqlalchemy/pkgdb.wsgi > httpd_t is allowed to read/use directories labeled httpd_user_content_t as > subdirs of /home/badger not directly there. > No scripts are directly in /home/badger. > The AVC's you attached shows httpd trying to search around in the /home/badger > directory, even searching the .local directory > Yep. I don't know why httpd is trying to do that. AFAIK, there's no reason that httpd needs to access .local > Can't you put your app in public_html/ directrory? > This should work even if the subdirectory isn't named public_html, though, right? SELinux should be operating based purely on what the subdirectory is labeled? Just to verify, I did this: $ mv /home/badger/pkgdb /home/badger/public_html $ restorecon -R /home/badger/public_html $ sudo vim /etc/httpd/conf.d/pkgdb.conf # Change the script to point to /home/badger/public_html/sqlalchemy/pkgdb.wsgi $ sudo /etc/init.d/httpd restart # Get AVC about .local $ curl https://localhost/pkgdb/ --insecure # Get AVC about .local # Get AVC about .rpmmacros # Get AVC about /var/run/pcscd.pub # Get AVC about reading user's home dirs. So I get the same thing even with the script inside of public_html. > > Toshio do you want to share your entire home directory via httpd? > No. Not at all. Is this script doing some kind of authentication? Is the package actually working? Looks like the tool is running rpm? Might be a tool you really can not test on a home dir with selinux in enforcing mode. (In reply to comment #7) > Is this script doing some kind of authentication? > Standard web-db stuff that should be invisible to the system it's running on. It doesn't change its unix userid, auth against pam, or anything like that. > Is the package actually working? > With SELinux off it does work. With SELinux on it doesn't work. With /home/badger labelled as httpd_user_content_t it works. > Looks like the tool is running rpm? > The tool is a python wsgi application. It imports koji. koji imports rpm. No rpm files are touched on disk. The rpm db is not intentionally touched by the application but I don't know what the koji module is doing under the hood. > Might be a tool you really can not test on a home dir with selinux in enforcing > mode. I don't know how to prove or disprove this statement ;-). Seems odd though -- all the files needed by the application reside under /home/badger/public_html/sqlalchemy/ and those are all labelled with httpd_user_content_t. Does the app work correctly even with SELinux complaining in enforcing mode? No. In enforcing mode the app fails. Well I am at a loss of what this app is trying to do. You can add all the rules as custom policy until you are done testing, or run httpd_t as a permissive domain. Okay. It seems to affect all the TurboGears with mod_wsgi apps that I've tried so far (packagedb, fedora account system), J5 reports that moksha/fedora-community may suffer from this as well. I've asked lmacken to try and reproduce it later this week and if so, he can bring you a system to try and diagnose what's wrong. So I wrote a quick test case and comment #1 made it work. Could have something to do with some of the external scripts or what the more elaborate code does. Things such as calling out to RPM or writing to a cache might be hitting permissions issues. The thing is when the startup of a wsgi script fails you don't get much feedback so it is hard to debug. BTW I think my issues weren't SELinux related. They happened because my home directory didn't have the execute bit enabled for all users. mod_wsgi needs to be able to list the files in the directories I guess. Created attachment 354646 [details]
test wsgi app
Created attachment 354647 [details]
apache config for wsgi sample
One of the things I have been thinking of adding as a boolean is htddp_read_user_content Since we have had to allow people.fedoraproject.org to read all users content. We can not rely on a user not screwing up scp xyz people.fedoraproject.org ssh people.fedoraproject.org mv xyz public_hmtl (Especially when I did it accidentally.) added boolean in selinux-policy-3.6.23-2.fc12.noarch Err... so is this closed WONTFIX because the boolean was reverted? Or because the boolean doesn't fix the actual problem? Or because it should have been closed RAWHIDE but you hit WONTFIX by mistake? :-) Reopening after talking to Dan at FUDCon. We think this might be mod_wsgi doing something it doesn't need to. This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |