Users and roles can play a part in an SELinux policy. However, the greater part of SELinux is Type Enforcement. Additionally, the targeted policy is designed not to utilize users and roles. Every domain in the targeted policy runs in a single role, and TE is used to separate the confined processes from the other processes.
This is why, when discussing interaction of processes and files, the type component is what you focus on.
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. 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. */
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.
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.
Roles can encompass other roles, inheriting the privileges of the included role. This dominance capability is not used in the targeted policy. This syntax example shows a role that is declared to dominate over, and inherit the privileges of, sysadm_r and user_r:
Linux UIDs and SELinux user identities should match because login and similar applications will try to look up the match. If it fails to find a match, it will fall back to user_u.