Configuring the SELinux Policy
unless there is an explicit auditallow rule. Permissions are always audited when denied unless there is an
explicit dontaudit rule.
3.2. RBAC Model
A traditional RBAC model authorizes users to act in certain roles, and assigns a set of permissions to
each role. The SELinux RBAC model authorizes each user for a set of roles, and authorizes each role for
a set of TE domains. A role dominance relationship can optionally be specified in the RBAC
configuration to define a hierarchy among roles. The assignment of permissions is primarily deferred to
the TE configuration. This approach combines the ease of management provided by the RBAC model
with the fine-grained protections provided by the TE model.
The SELinux RBAC model maintains a role attribute in the security context of each process. For objects,
the role attribute is typically set to a generic object_r role and is unused. Role transitions for processes
are controlled through a combination of the RBAC and TE models. The RBAC configuration specifies
authorized transitions between roles based on the pair of roles. However, it is also desirable to limit role
transitions to certain programs to ensure that malicious code cannot cause such transitions. Hence, role
transitions are typically limited to certain TE domains in the policy configuration.
3.3. User Identity Model
The Linux user identity attributes are unsuitable for use by SELinux. Linux uids are often changed
simply to express a change in permissions or privileges as opposed to a change in the actual user, posing
problems for user accountability. Linux uids can be changed at any time via the set*uid calls, providing
no control over the inheritance of state or the initialization of the process in the new identity. Linux uids
can be arbitrarily changed by superuser processes.
Rather than imposing new restrictions on the Linux user identity attributes, SELinux maintains a user
identity attribute in the security context that is independent of the Linux user identity attributes. By using
a separate user identity attribute, the SELinux mandatory access controls remain completely orthogonal
to the existing Linux access controls. SELinux can enforce rigorous controls over changes to its user
identity attribute without affecting compatibility with Linux uid semantics.
The policy configuration limits the ability to change the SELinux user identity attribute to certain TE
domains. These domains are associated with certain programs, such as login, crond and sshd, that have
been modified to call new library functions to set the SELinux user identity appropriately. Hence, user
login sessions and cron jobs are initially associated with the appropriate SELinux user identity, but
subsequent changes in the Linux uid may not be reflected in the SELinux user identity. In some cases,
this is desirable in order to provide user accountability or to prevent security violations. In some
distributions that have integrated SELinux support, the su program also changes the SELinux user
identity to the new user identity, while other distributions leave the SELinux user identity unchanged by
su.
Since the SELinux user identity is independent of the Linux uid, it is possible to maintain separate user
identity spaces for SELinux and Linux, with an appropriate mapping performed by the programs that set
the SELinux user identity. For example, rather than maintaining a separate entry for each Linux user in
the SELinux policy, it may be desirable to map most Linux users to a single SELinux user that is
6