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:
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.
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.)
This role is for all system processes except user processes:
system_r (28 types)
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
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
, and the role is only used as a placeholder in the label.
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 the
newrole -r sysadm_r command to change to the SELinux system administrator role to perform system administration tasks. In the targeted policy, the following retain
sysadm_r for compatibility:
sysadm_r (6 types)
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.
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