Show Table of Contents
49.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.
49.8.1. What is the Targeted Policy?
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 Strict Policy
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.
Note
Depending on your installation, only some of these daemons may be present.
49.8.2. Files and Directories of the Targeted Policy
Refer to Section 49.7.2, “Where is the Policy?” for a list of the common files and directories used by SELinux.
49.8.3. Understanding the Users and Roles in the Targeted Policy
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.[20]
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.)
system_r- 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 user_r- 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_tdomain. object_r- 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. sysadm_r- 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 thenewrole -r sysadm_rcommand to change to the SELinux system administrator role to perform system administration tasks. In the targeted policy, the following retainsysadm_rfor 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.[21]
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.
[20]
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.
[21]
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.
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.