Building on your understanding from reading Section 2.10 SELinux Users and Roles, this section covers the specific roles enabled for the targeted policy. As explained previously, roles are not very active in the targeted policy, but can be an essential part of a localized SELinux installation. You can see that unconfined_t is in every role, which significantly reduces the usefulness of roles in the targeted policy. Using roles more extensively 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 strict policy.[1]
Of the four roles, three are defined by the policy. The role object_r is an implied role and is not found in policy source. Since roles are created and populated by types through one or more declarations in $SELINUX_SRC/domains/*, there is not a single file that declares all the roles. To generate the lists of types and their roles in this section, the policy analysis tool apol was used. Usage of this tool is explained in Section 6.3 Using apol for Policy Analysis.
This role is for all system processes except user processes:
unconfined_t httpd_t httpd_sys_script_t httpd_suexec_t httpd_php_t httpd_helper_t dhcpd_t ldconfig_t mailman_queue_t mailman_mail_t mailman_cgi_t system_mail_t mysqld_t named_t ndc_t nscd_t ntpd_t portmap_t postgresql_t snmpd_t squid_t syslogd_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 do privileged operations. In the targeted policy, all users run in a single domain:
unconfined_t |
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 doers, which are subjects. For this reason, all objects universally 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. In such a policy, switching to the root user with su gives you the role of sysadm_r. However, if you login directly as the root user, you may default to staff_r and still need to run newrole -r sysadm_r before doing many system administration tasks. In the targeted policy, the following retain sysadm_r for compatibility:
unconfined_t httpd_sys_script_t httpd_helper_t ldconfig_t ndc_t |
Similar to the situation for roles, there is effectively only one user identity in the targeted policy. The identity user_u 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 switch to the strict policy. The remaining users exist for compatibility with the strict policy.[2]
The one exception is the SELinux user root. This user identity is picked up by login programs such as su, and 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.
Here is a brief look at the $SELINUX_SRC/users file. Comments in /* */ are annotations from this guide, all other content is original source from the users file.
src/policy/users
# Each user has a set of roles that may be entered by
# processes with the users identity. The syntax of a user
# declaration is: #
# user username roles role_set [ ranges MLS_range_set ];
# system_u is the user identity for system processes and
# objects. There should be no corresponding Unix user
# identity for system_u, and a user process should never be
# assigned the system_u user identity.
user system_u roles system_r;
/* ^- user name ^- the role user name can have */
# user_u is a generic user identity for Linux users who have
# no SELinux user identity defined. Authorized for all
# roles in the (targeted) policy. sysadm_r is retained for
# compatibility, but could be dropped as long as userspace
# has no hardcoded dependency on it. user_u must be
# retained due to present userspace hardcoded dependency.
user user_u roles { user_r sysadm_r system_r };
/* ^-user name ^-set of roles the user name can have */
# root is retained as a separate user identity simply as a
# compatibility measure with the "strict" policy. It could
# be dropped and mapped to user_u but this allows existing
# file contexts that have "root" as the user identity to
# remain valid.
user root roles { user_r sysadm_r system_r };
/* ^user name ^- set of roles */ |
| [1] | Any of the roles 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 in this fashion because there is no role aliasing mechanism. |
| [2] | A user aliasing mechanism would work here, as well, to alias all identities from the strict policy to a single user identity in the targeted policy. |