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.
