This explanation is not very informative, but it does tell us that there is no type enforcement rule to allow this access, and that may be because of a boolean setting. Viewing the manpage for httpd_selinux gives information about the necessary boolean setting, along with the required context labeclass="underline"
httpd by default is not allowed to access users home directories. If you want to allow access to users home directories you need to set the httpd_enable_homedirs boolean and change the context of the files that you want people to access off the home dir.
setsebool -P httpd_enable_homedirs 1
chcon -R -t httpd_sys_content_t ~user/public_html
Issuing the commands given in the manpage fixes the problem. Here I've substituted the actual user's name into the chcon argument:
# setsebool -P httpd_enable_homedirs
# chcon -R -t httpd_sys_content_t ~chris /public_html
Fedora Core 6 includes the first release of the setroubleshoot tool, which provides a desktop notification of AVC denials as well as a GUI program for analyzing AVC messages. To use this tool, install the setroubleshoot package.
8.2.2. How Does It Work?
The Linux kernel provides the Linux Security Module (LSM) interface to enable additional access controls to be added to operations. These interfaces provide connections, or hooks , into the system call code used by processes to request that the kernel perform an operation, such as opening a file, sending a signal to another process, or binding to a network socket.
SELinux uses these hooks to permit or deny requests made by a process ( subject ) on a resource (such as a file, network socket, or another process, called an object ). These controls are called mandatory access controls (MAC) because they enforce a consistent security policy across the entire system. This stands in contrast to the traditional Unix/Linux file permissions, which are considered discretionary access controls (DAC) because the access settings are left to each user's discretion.
SELinux does not override permissions; access to a resource must be permitted by all security mechanismsincluding SELinux, permission modes, ACLs, mount options, and filesystem attributesbefore it will be granted.
An SELinux policy defines the rules used to make each access decision. There are three inputs into each decision: the security context of the source subject, and the security context and class of the target object.
Each security context consists of four parts: a user , a role , a type , and a sensitivity . In order to track this information, SELinux assigns a label to each subject and object.
You can view the context of processes by using the -Z (or --context ) argument with the ps command:
$ ps -e -Z
LABEL PID TTY TIME CMD
system_u:system_r:init_t 1 ? 00:00:02 init
system_u:system_r:kernel_t 2 ? 00:00:00 ksoftirqd/0
system_u:system_r:kernel_t 3 ? 00:00:00 watchdog/0
system_u:system_r:kernel_t 4 ? 00:00:00 events/0
...Lines snipped...
user_u:system_r:unconfined_t 24168 pts/2 00:00:00 bash
user_u:system_r:unconfined_t 24228 pts/2 00:00:00 ps
user_u:system_r:unconfined_t 24229 pts/2 00:00:00 tail
This information is also displayed by the GNOME System Monitor, as shown in Figure 8-7 .
If you've added the System Monitor applet to your GNOME panel, clicking on it will start the GNOME System Monitor. You can also start it using the menu entry ApplicationsSystem ToolsSystem Monitor, or by typing the command gnome-system-monitor.
Figure 8-7. GNOME System Monitor display showing the security contexts of processes
The label on the init process (highlighted in Figure 8-7 ) indicates that the user is system_u , the role is system_r , and the type is init_t . The sensitivity is not shown in this output. This label defines the source security context ( scontext ) because the init process is a source of system access requests.
_t indicates a type, _r indicates a role, and _u indicates a user
When init attempts to read the configuration file /etc/inittab , the label on that file defines the target security context ( tcontext ):
$ ls -Z /etc/inittab
-rw-r--r-- root root system_u:object_r:etc_t /etc/inittab
Context labels on files are stored in the file's attributes, and therefore SELinux can be used only on filesystems that support these attributes: ext2, ext3, and XFS. Other filesystems, such as ReiserFS, JFS, ISO9660, and VFAT do not support these attributes yet.
You can view the context labels as a file attribute using the getfattr command, specifying the security.selinux attribute name:
# getfattr -n security.selinux /etc/hosts
getfattr: Removing leading '/' from absolute path names
# file: etc/hosts
security.selinux="system_u:object_r:etc_t:s0\000"
The last portion of the security.selinux attribute is the sensitivity level, which is used only for multilevel security (MLS) and multicategory security (MCS). The \000 at the end of the attribute indicates an ASCII NUL character, used to delimit the end of the attribute in traditional C style.
The target class ( tclass ) associated with the object being accessed is determined by the type of object (and in some cases, how it is being accessed); in this example, where init is attempting to access /etc/inittab , the tclass is file . Therefore the SELinux policy is checked to see if access is permitted for an scontext of system_u:system_r:init_t , a tcontext of system_u:object_r:etc_t , and a tclass of file . To speed access, SELinux rules are cached in an area of memory called the access vector cache which explains why SELinux error messages are labeled avc .
The Fedora project has three policies available:
targeted
The default policy installed with Fedora Core. This policy is targeted for the protection of the most frequently attacked portions of the system, including most network services. Programs that are not targeted are unconstrained by SELinux.
strict
This policy denies every action except those explicitly permitted. Although this should be more secure than the targeted policy, it's hard to create a policy that encompasses all possible configurations of all programs that can be installed on a Fedora system, and attempting to use this policy has frustrated many system administrators into turning off SELinux altogether. In other words, the targeted policy is often more secure simply because it's more likely to be used.