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.
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.
- system_r
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 |
- 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 do privileged operations. In the targeted
policy, all users run in a single domain:
- 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 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.
- sysadm_r
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.
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 */ |
