Bug 509943 - Have to change home directory to httpd_user_content_t when SELinux is enforcing
Summary: Have to change home directory to httpd_user_content_t when SELinux is enforcing
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 11
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-07-07 02:43 UTC by Toshio Ernie Kuratomi
Modified: 2010-06-28 13:30 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-06-28 13:30:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
audit.log (2.22 KB, application/octet-stream)
2009-07-10 20:22 UTC, Toshio Ernie Kuratomi
no flags Details
test wsgi app (138 bytes, application/octet-stream)
2009-07-22 04:26 UTC, John (J5) Palmieri
no flags Details
apache config for wsgi sample (528 bytes, application/octet-stream)
2009-07-22 04:28 UTC, John (J5) Palmieri
no flags Details

Description Toshio Ernie Kuratomi 2009-07-07 02:43:47 UTC
Description of problem:
 This could be a documentation bug in setroubleshoot or a bug in policy or just me being dense.  Apologies if it's the latter:

I'm trying to run a web application from my home directory in order to test it.  It's being run via mod_wsgi which means that apache loads the code and executes it in an apache worker.

SELinux denies access to the script.
SEtroubleshoot tells me to set httpd_enable_homedirs to 1
I do so but the problem remains.
I try setting the labels of the files from unconfined_u:object_r:user_home_t:s0 to either system_u:object_r:httpd_sys_script_exec_t:s0 or unconfined_u:object_r:httpd_user_content_t:s0 using chcon.
This lets apache proceed but I have to change the label on all the containing directories up to my home directory, not just the label on the subdirectory of my home dir that I have the program I'm testing in.  That seems like it's not the correct behaviour.

I now have:
drwxr-xr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger
drwxrwxr-x. badger badger unconfined_u:object_r:httpd_user_content_t:s0 /home/badger/pkgdb

and the same for all the contents of pkgdb.  I would expect
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 /home/badger/pkgdb

When this is turned on:
# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.6.12-62.fc11.noarch.rpm

Comment 1 Daniel Walsh 2009-07-09 12:44:08 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.

Comment 2 Toshio Ernie Kuratomi 2009-07-10 20:19:56 UTC
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/

Comment 3 Toshio Ernie Kuratomi 2009-07-10 20:22:37 UTC
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.

Comment 4 Toshio Ernie Kuratomi 2009-07-10 20:28:20 UTC
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.

Comment 5 Daniel Walsh 2009-07-14 12:49:14 UTC
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

Comment 6 Toshio Ernie Kuratomi 2009-07-14 17:44:49 UTC
(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.

Comment 7 Daniel Walsh 2009-07-14 20:02:43 UTC
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.

Comment 8 Toshio Ernie Kuratomi 2009-07-14 22:36:48 UTC
(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.

Comment 9 Daniel Walsh 2009-07-15 14:52:40 UTC
Does the app work correctly even with SELinux complaining in enforcing mode?

Comment 10 Toshio Ernie Kuratomi 2009-07-15 16:14:10 UTC
No.  In enforcing mode the app fails.

Comment 11 Daniel Walsh 2009-07-21 12:40:29 UTC
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.

Comment 12 Toshio Ernie Kuratomi 2009-07-21 17:38:24 UTC
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.

Comment 13 John (J5) Palmieri 2009-07-22 04:25:19 UTC
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.

Comment 14 John (J5) Palmieri 2009-07-22 04:26:41 UTC
Created attachment 354646 [details]
test wsgi app

Comment 15 John (J5) Palmieri 2009-07-22 04:28:29 UTC
Created attachment 354647 [details]
apache config for wsgi sample

Comment 16 Daniel Walsh 2009-07-23 15:01:36 UTC
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.)

Comment 17 Daniel Walsh 2009-07-27 18:14:44 UTC
added boolean in selinux-policy-3.6.23-2.fc12.noarch

Comment 18 Toshio Kuratomi 2009-08-22 00:13:27 UTC
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?  :-)

Comment 19 Toshio Ernie Kuratomi 2009-12-06 17:18:56 UTC
Reopening after talking to Dan at FUDCon.  We think this might be mod_wsgi doing something it doesn't need to.

Comment 20 Bug Zapper 2010-04-27 15:31:19 UTC
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

Comment 21 Bug Zapper 2010-06-28 13:30:17 UTC
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.


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