43.8. Targeted Policy Overview
This chapter is an overview and examination of the SELinux targeted policy, the current supported policy for Red Hat Enterprise Linux.
Much of the content in this chapter is applicable to all types of SELinux policy, in terms of file locations and the type of content in those files. The difference lies in which files exist in the key locations and their contents.
The SELinux policy is highly configurable. For Red Hat Enterprise Linux 5, Red Hat supports a single policy, the targeted policy. Under the targeted policy, every subject and object runs in the unconfined_t domain except for the specific targeted daemons. Objects that are in the unconfined_t domain have no restrictions and fall back to using standard Linux security, that is, DAC. The daemons that are part of the targeted policy run in their own domains and are restricted in every operation they perform on the system. This way daemons that are exploited or compromised in any way are contained and can only cause limited damage.
For example, the http and ntp daemons are both protected in the default targeted policy, and run in the httpd_t and ntpd_t domains, respectively. The ssh daemon, however, is not protected in this policy, and consequently runs in the unconfined_t domain.
Refer to the following sample output, which illustrates the various domains for the daemons mentioned above:
user_u:system_r:httpd_t 25129 ? 00:00:00 httpd user_u:system_r:ntpd_t 25176 ? 00:00:00 ntpd system_u:system_r:unconfined_t 25245 ? 00:00:00 sshd
The opposite of the targeted policy is the strict policy. In the strict policy, every subject and object exists in a specific security domain, and all interactions and transitions are individually considered within the policy rules.
The strict policy is a much more complex environment, and does not ship with Red Hat Enterprise Linux. This guide focuses on the targeted policy that ships with Red Hat Enterprise Linux, and the components of SELinux used by the targeted daemons.
The targeted daemons are as follows: dhcpd; httpd; mysqld; named; nscd; ntpd; portmap; postgres; snmpd; squid; syslogd; and winbind.
Depending on your installation, only some of these daemons may be present.
Refer to Section 43.7.2, “Where is the Policy?” for a list of the common files and directories used by SELinux.
This section covers the specific roles enabled for the targeted policy. The unconfined_t type exists in every role, which significantly reduces the usefulness of roles in the targeted policy. More extensive use of roles requires a change to the strict policy paradigm, where every process runs in an individually considered domain.
Effectively, there are only two roles in the targeted policy: system_r and object_r. The initial role is system_r, and everything else inherits that role. The remaining roles are defined for compatibility purposes between the targeted policy and the strict policy.[21]
Three of the four roles are defined by the policy. The fourth role, object_r, is an implied role and is not found in policy source. Because roles are created and populated by types using one or more declarations in the policy, there is no single file that declares all roles. (Remember that the policy itself is generated from a number of separate files.)
This role is for all system processes except user processes:
system_r (28 types)
dhcpd_t
httpd_helper_t
httpd_php_t
httpd_suexec_t
httpd_sys_script_t
httpd_t
httpd_unconfined_script_t
initrc_t
ldconfig_t
mailman_cgi_t
mailman_mail_t
mailman_queue_t
mysqld_t
named_t
ndc_t
nscd_t
ntpd_t
pegasus_t
portmap_t
postgresql_t
snmpd_t
squid_t
syslogd_t
system_mail_t
unconfined_t
winbind_helper_t
winbind_t
ypbind_t
This is the default user role for regular Linux users. In a strict policy, individual users might be used, allowing for the users to have special roles to perform privileged operations. In the targeted policy, all users run in the unconfined_t domain.
In SELinux, roles are not utilized for objects when RBAC is being used. Roles are strictly for subjects. This is because roles are task-oriented and they group together entities which perform actions (for example, processes). All such entities are collectively referred to as subjects. For this reason, all objects have the role object_r, and the role is only used as a placeholder in the label.
This is the system administrator role in a strict policy. If you log in directly as the root user, the default role may actually be staff_r. If this is true, use the newrole -r sysadm_r command to change to the SELinux system administrator role to perform system administration tasks. In the targeted policy, the following retain sysadm_r for compatibility:
sysadm_r (6 types)
httpd_helper_t
httpd_sys_script_t
initrc_t
ldconfig_t
ndc_t
unconfined_t
There is effectively only one user identity in the targeted policy. The user_u identity was chosen because libselinux falls back to user_u as the default SELinux user identity. This occurs when there is no matching SELinux user for the Linux user who is logging in. Using user_u as the single user in the targeted policy makes it easier to change to the strict policy. The remaining users exist for compatibility with the strict policy.[22]
The one exception is the SELinux user root. You may notice root as the user identity in a process's context. This occurs when the SELinux user root starts daemons from the command line, or restarts a daemon originally started by init.
[21] Any role could have been chosen for the targeted policy, but system_r already had existing authorization for the daemon domains, simplifying the process. This was done because no mechanism currently exists to alias roles.
[22] A user aliasing mechanism would also work here, to alias all identities from the strict policy to a single user identity in the targeted policy.