Chapter 24. Policy: 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 user access and even 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.
24.1. About Identity Management, SELinux, and Mapping Users
Note
Identity Management does not create or modify the SELinux contexts on a system. Rather, it uses existing contexts as the basis to map IdM users (in the domain) to SELinux users (on a system).
Security-enhanced Linux defines kernel-level, mandatory access controls for how users, processes, and applications can interact with other resources on a system. These rules for interactions, called contexts, look at the data and behavior characteristics of different objects on the system and then set rules, called policies, based on the security implications of each specific object. This is in contrast to higher-level discretionary access controls which are concerned primarily with file ownership and user identity, without accounting for data criticality or applciation behavior. Every resource on a system (users, applications, files, processes) is assigned a context.
System users are associated with an SELinux role. The role is assigned both a multi-layer security context (MLS) a multi-category security context (MCS). The MLS/MCS contexts confine users to what processes, files, and operations they can access on the system.
Figure 24.1. SELinux Users in the SELinux Manager
This is all described in detail in Red Hat Enterprise Linux 6 Security-Enhanced Linux.
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 — SELinux has common defined system users and SELinux-aware services define their own policies — it has some issues when dealing with remote users and systems that access local resources. Remote users and services can get shuffled into a default guest context without a lot of intelligence about what their actual SELinux user and role should be.
This is how Identity Management can cleanly integrate an identity domain with local SELinux services. Identity Management can map IdM users to configured SELinux roles per host. 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.
- SELinux users are automatically updated as hosts are added to the IT environment or as users are added, removed, or changed, without having to edit local systems.
- 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.
SELinux user maps are comprised of three parts: the SELinux user for the system, an IdM user, and an IdM host. These define two separate relationships. First, it defines a map for the SELinux user on a specific host (the local or target system). Second, it defines a map for 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.
SELinux user maps work with the Systerm 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.
The core of an SElinux mapping rule is the SELinux system user. Each map is associated with the SELinux user first. The SELinux users which are available for mapping are configured in the IdM server, so there is a central and universal list. These are SELinux users which are configured on every host in the IdM domain. By default, there are five common SELinux users defined:
- unconfined_u (also used as a default for IdM users)
- guest_u
- xguest_u
- user_u
- staff_u
In the IdM server configuration, each SELinux user is configured with both its username and its MLS/MCS range, SELinux_username:MLS[:MCS], and this format is used 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 individually, or user groups or host groups can be explicitly assigned to the map.
An extra layer of security is possible by using host-based access control rules. As long as the host-based access control rule defines a user and a host, it can be used for an SELinux user map. Host-based access control rules (described in Chapter 22, Policy: 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 defining 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.
