Bug 453947

Summary: SELinux prevents Apache from reading files in /var/www/html/
Product: [Fedora] Fedora Reporter: Christopher Beland <beland>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: low    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-03 15:29:59 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 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.