2.10. SELinux Users and Roles

2.10.1. SELinux Roles

Roles define which SELinux user identities can have access to what domains. Roles are created by the existence of one or more declarations in a TE rules file in $SELINUX_SRC/domains/*:

Simply being in a role is not enough to allow domain transition. If a process is in role_r and domain1_t, and role_r is authorized for domain2_t, the process cannot jump to domain2_t. There must be an allow rule for the process transition to take place.

For example, the domains named_t and squid_t are both in the role system_r. However, named_t cannot transition to squid_t without an allow rule.

This shows the syntax and an allow example for role:

# syntax for role declaration

role <rolename> types <domain(s)>;

# example of role declaration from 
# $SELINUX_SRC/domains/programs/ldconfig.te

role sysadm_r types ldconfig_t;
/* administrators are allowed access to ldconfig_t domain */


# syntax for role allow

allow <current_role(s)> <new_role(s)>;

# example of role allow from $SELINUX_SRC/rbac

allow user_r sysadm_r;

Grouping domains into roles is relatively intuitive, since roles are task-oriented[1]. Every process has a role, starting with the system role, system_r. Users gain a role at login, which includes using su where a new role can come with the new UID, or you can keep your UID and change your role using newrole; however, this is not often done. Domains are changed often and quietly, but roles rarely change, especially under the targeted policy. Another way to change roles is through a role_transition, this is also very rare and currently only used for an administrative role to launch daemons in a different role under a stricter policy:

role_transition sysadm_r $1_exec_t system_r;
/* When an administrator executes a process with the type of */
/* $1_exec_t, the process transitions from sysadm_r to       */
/* system_r.                                                 */

2.10.2. SELinux Users

SELinux user identities are different from UNIX identities. They are applied as part of the security label and can be changed in real time under limited conditions. SELinux identities are not primarily used in the targeted policy. In the targeted policy, processes and objects are system_u, and the default for Linux users is user_u. When identities are part of the policy scheme, they are usually identical to the Linux account name (UID), and are compiled into the policy. In such a strict policy, some system accounts may run under a generic, unprivileged user_u identity, while other accounts have direct identities in the policy database.[2]

For a review of the roles and users, including a discussion of the $SELINUX_SRC/users file, refer to Section 3.5 Understanding the Roles and Users in the Targeted Policy.