Chapter 49. Defining SELinux user maps

Learn how Security-Enhanced Linux (SELinux) contexts and policy stay on each host while Identity Management (IdM) maps domain users to SELinux user strings at login.

SELinux provides kernel-level mandatory access control (MAC) to govern how processes interact with system resources. Based on the expected behavior of processes and their security implications, administrators and policy writers define security contexts. These are labels assigned to every subject, such as processes, and object, such as files, sockets, and hardware on the system.

While the kernel only sees subjects (processes) and objects (files or sockets), the chain of security begins with the human identity. When a user logs in via IdM, their network account is mapped to a specific SELinux user. This mapping acts as a bridge: it ensures that every process started by that human inherits a specific security context.

Consequently, a human does not just have access to a file; instead, the human’s identity determines their SELinux label, and that label dictates exactly which resources their processes can access. By assigning different contexts to different groups of people, such as administrators, developers, or guests, organisations can ensure that even if a human’s session is compromised, the blast radius of a security breach is effectively minimized.

IdM does not create or modify SELinux contexts or policy on client systems. Instead, IdM uses strings that can match contexts already present on target hosts as the basis for mapping IdM users in the domain to SELinux users on a system.

If you create an SELinux user map in IdM, you do not modify the SELinux policy on your hosts:

Each SELinux user is associated with one or more SELinux roles. The role is assigned both a multilayer security (MLS) context and a multi-category security (MCS) context. The MLS and MCS contexts confine users so that they can access only certain processes, files, and operations on the system.

The following list maps SELinux users that are available on a system to their allowed roles:

                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

SELinux user maps work with the System Security Services Daemon (SSSD) and the pam_selinux PAM module. When a remote user logs in to a machine, SSSD queries its IdM identity provider for user information, including any SELinux maps. The PAM module then assigns the appropriate SELinux user context. SSSD caching allows the mapping to work while offline.

Learn how mapping Identity Management (IdM) users to SELinux users centralizes SELinux context assignment and ties it to identity, host, and host-based access policy in the IdM domain.

SELinux users and policies operate at the system level, not the network level. SELinux users are configured independently on each system. While that is acceptable in many environments because SELinux defines common system users and SELinux-aware services define their own policies, it can be problematic when remote users and systems access local resources. Remote users and services might receive a default SELinux context that does not match their intended identity or role.

IdM solves this problem by integrating an identity domain with local SELinux services. IdM can map IdM users to configured SELinux users per host, per host group, or based on a host-based access control (HBAC) rule. Specifically, mapping SELinux and IdM users improves user administration as follows:

An SELinux user map links an IdM user to a specific SELinux user on a per-host basis. This allows administrators to assign different security contexts to the same person depending on which system they access.

Learn how Identity Management (IdM) maintains a central list of SELinux user strings with MLS and MCS ranges that you attach to maps and assign at login.

The core of an SELinux user map is the SELinux user. Each map is associated with an SELinux user. The SELinux users available for mapping are configured centrally in IdM. By default, these include:

You can change this default list: any native SELinux user can be added or removed from the central IdM SELinux user list.

In the IdM server configuration, each SELinux user is configured with its user name and its MLS and MCS range, in the form SELinux_user:MLS[:MCS]. The IdM server uses this format when configuring maps.

HBAC rules integrate with SELinux user maps in Identity Management (IdM) so that the same user and host membership controls both access and SELinux context assignment.

You can associate SELinux mapping rules with HBAC rules to simplify administration and avoid duplicating membership in separate map and HBAC definitions. As long as the HBAC rule defines a user and a host, you can use it for an SELinux user map. Linking an SELinux user map to an HBAC rule ensures that the same user and host membership drives both access enforcement and SELinux context assignment.

If an HBAC rule is associated with an SELinux user map, you cannot delete the host-based access control rule until you remove it from the SELinux user map configuration.

Learn about how to configure the SELinux user map order and the default SELinux user on the IdM server so that unmapped domain users still receive a valid context and so that the server ranks SELinux users from most confined to least confined.

The SELinux user map order is a list of SELinux users ranked from most confined to least confined. It is part of the IdM server configuration. An SELinux user map associates an SELinux user on a client with an Identity Management (IdM) user.

Each SELinux user entry uses this format:

SELinux_user:MLS[:MCS]

Separate individual user entries with a dollar sign ($).

Because IdM user entries do not require an SELinux map, many entries might be unmapped. The IdM server configuration defines a default SELinux user—one of the users from the full SELinux map list—for unmapped IdM user entries so that those users still receive a valid SELinux context. The default SELinux user for unmapped IdM user entries is unconfined_u, which is consistent with the default SELinux user for system users on Red Hat Enterprise Linux.

Use the Identity Management (IdM) Web UI to set the SELinux user map order, the default SELinux user for unmapped IdM entries, and which SELinux users are available for mapping on the IdM server. This controls how strictly unmapped users are confined and which strings maps may use.

Use the Identity Management (IdM) CLI to set the SELinux user map order, the default SELinux user for unmapped IdM entries, and which SELinux users are available for mapping in IdM. This controls how strictly unmapped users are confined and which strings maps may use.

Create or edit SELinux user maps in the Identity Management (IdM) Web UI to associate an SELinux user context on IdM clients with IdM users, groups, hosts, host groups, or with a single host-based access control (HBAC) rule.

Create or edit SELinux user maps in the Identity Management (IdM) CLI to associate an SELinux user context on IdM clients with IdM users, groups, hosts, host groups, or with a single host-based access control (HBAC) rule.