Chapter 32. Defining SELinux User Maps Security-enhanced Linux (SELinux) sets rules over what system users can access processes, files, directories, and system settings. Both the system administrator and system applications can define security contexts that restrict or allow access from other applications. As part of defining centralized security policies in the Identity Management domain, Identity Management provides a way to map IdM users to existing SELinux user contexts and grant or restrict access to clients and services within the IdM domain, per host, based on the defined SELinux policies. 32.1. About Identity Management, SELinux, and Mapping Users Identity Management does not create or modify the SELinux contexts on a system. Rather, it uses strings that might match existing contexts on the target hosts as the basis for mapping IdM users in the domain to SELinux users on a system. Security-enhanced Linux defines kernel-level, mandatory access controls for how processes can interact with other resources on a system. Based on the expected behavior of processes on the system, and on their security implications, specific rules called policies are set. This is in contrast to higher-level discretionary access controls which are concerned primarily with file ownership and user identity. Every resource on a system is assigned a context. Resources include users, applications, files, and processes. System users are associated with an SELinux role . The role is assigned both a multilayer security context (MLS) and a multi-category security context (MCS). The MLS and MCS contexts confine users so that they can only access certain processes, files, and operations on the system. To get the full list of available SELinux users: For more information about SELinux in Red Hat Enterprise Linux, see Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide . SELinux users and policies function at the system level, not the network level. This means that SELinux users are configured independently on each system. While this is acceptable in many situations, as SELinux has common defined system users and SELinux-aware services define their own policies, it causes problems when remote users and systems access local resources. Remote users and services can be assigned a default guest context without knowing what their actual SELinux user and role should be. Identity Management can integrate an identity domain with local SELinux services. Identity Management can map IdM users to configured SELinux roles per host, per host group , or based on an HBAC rule . Mapping SELinux and IdM users improves user administration: Remote users can be granted appropriate SELinux user contexts based on their IdM group assignments. This also allows administrators to consistently apply the same policies to the same users without having to create local accounts or reconfigure SELinux. The SELinux context associated with a user is centralized. SELinux policies can be planned and related to domain-wide security policies through settings like IdM host-based access control rules. Administrators gain environment-wide visibility and control over how users and systems are assigned in SELinux. An SELinux user map defines two separate relationships that exist between three parts: the SELinux user for the system, an IdM user, and an IdM host. First, the SELinux user map defines a relationship between the SELinux user and the IdM host (the local or target system). Second, it defines a relationship between the SELinux user and the IdM user. This arrangement allows administrators to set different SELinux users for the same IdM users, depending on which host they are accessing. The core of an SELinux mapping rule is the SELinux system user. Each map is first associated with an SELinux user. The SELinux users which are available for mapping are configured in the IdM server, so there is a central and universal list. In this way, IdM defines a set of SELinux users it knows about and can associate with an IdM user upon login. By default, these are: unconfined_u (also used as a default for IdM users) guest_u xguest_u user_u staff_u However, this default list can be modified and any native SELinux user (see Section 32.1, "About Identity Management, SELinux, and Mapping Users" ) can be added or removed from the central IdM SELinux users list. In the IdM server configuration, each SELinux user is configured with not only its user name but also its MLS and MCS range, SELinux_user:MLS[:MCS] . The IPA server uses this format to identify the SELinux user when configuring maps. The IdM user and host configuration is very flexible. Users and hosts can be explicitly and individually assigned to an SELinux user map, or user groups or host groups can be explicitly assigned to the map. You can also associate SELinux mapping rules with host-based access control rules to make administration easier, to avoid duplicating the same rule in two places, and to keep the rules synchronized. As long as the host-based access control rule defines a user and a host, you can use it for an SELinux user map. Host-based access control rules (described in Chapter 31, Configuring Host-Based Access Control ) help integrate SELinux user maps with other access controls in IdM and can help limit or allow host-based user access for remote users, as well as define local security contexts. Note If a host-based access control rule is associated with an SELinux user map, the host-based access control rule cannot be deleted until it is removed from the SELinux user map configuration. SELinux user maps work with the System Security Services Daemon (SSSD) and the pam_selinux module. When a remote user attempts to log into a machine, SSSD checks its IdM identity provider to collect the user information, including any SELinux maps. The PAM module then processes the user and assigns it the appropriate SELinux user context. SSSD caching enables the mapping to work offline.

Commands:
semanage user -l Labelling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles guest_u user s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r