Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 453947 - SELinux prevents Apache from reading files in /var/www/html/
Summary: SELinux prevents Apache from reading files in /var/www/html/
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-03 13:09 UTC by Christopher Beland
Modified: 2008-07-03 19:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-03 15:29:59 UTC


Attachments (Terms of Use)

Description Christopher Beland 2008-07-03 13:09:30 UTC
I had a directory called /home/beland/www, which I wanted to publish.  So, I
moved it to /var/www/html/beland.  When trying to load my homepage, I got the
following error in the Apache log:

(13)Permission denied: access to /beland/useful.html denied

In order to fix this without using the command line, I had to change SELinux
from "enforcing" to "permissive".

The error message I got from setroubleshoot says:

>>

SELinux has denied httpd access to potentially mislabeled file(s)
(./useful.html). This means that SELinux will not allow httpd to use these
files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is that
the files end up with the wrong file context which confined applications are not
allowed to access.

Allowing Access:

If you want httpd to access this files, you need to relabel them using
restorecon -v './useful.html'. You might want to relabel the entire directory
using restorecon -R -v '.'.

<<

This is not very user friendly.  The problem is being caused by an invisible
attribute of the files (as far as most people are concerned) having to do with
where they came from rather than where they are.  It doesn't make sense that the
security system would prevent Apache from accessing files *in the directory
specifically dedicated to storing files Apache is supposed to access*.  This
over-protectiveness makes people more likely to disable the security system,
leading to increased risk of break-in.

This is with:

selinux-policy-targeted-3.3.1-72.fc9.noarch
httpd-2.2.8-3.x86_64

Comment 1 Daniel Walsh 2008-07-03 15:29:59 UTC
Chris is you moved a file to this directory and it was owned by root and had 600
permissions on it, would you expect it to just work?  With a mandadtory access
system you need to not only make sure that files have the correct ownership,
file permissions and Labels associated with them.  SELinux does not and cannot
rely on path, so labels on the inode is required.



Comment 2 Christopher Beland 2008-07-03 17:25:35 UTC
What is the security purpose in denying Apache access to these files?  Why can't
the system be made any smarter than it is now?  If "restorecon" knows what
labels these files *should* have, why is manual intervention necessary?  Why
aren't the labels set properly on the fly?

Unix permissions are something I can fix in Nautilus.  I can see the SELinux
context there, but I can't do anything about it, and it's not obvious what
*should* be done about it.  I don't think users *should* have to learn how
SELinux works in order to be able to use their computers; it adds too much
complexity to an understanding that is already pretty complicated.

Comment 3 Daniel Walsh 2008-07-03 19:10:53 UTC
Probably nothing. But these files are labeled as user_home_t, which is the label
of most files in your home directory.  If a compromized apache server is taken
over you would probably not want it to access you home directory contents.  Now
you can argue that the mv/cp/install tools should handle this in a smarter
fashion.  But they work the same way for DAC.  So upstream for coreutils wants
MAC to follow the pattern.  nautilus used to have the ability to change the
context and I believe this is a bug in Fedora 9 that has been fixed in Rawhide.

If you want to continue this discussion, please move it to email or a fedora list.




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