Course contentsShow
← Linux
Lesson 859 of 1,8198. User Management and Pluggable Authentication ModulesFree lesson

Implementing System-wide SELinux User Mapping

You will define security contexts that restrict what users can execute based on their authenticated identity.

In this lesson, you will learn how to enforce security boundaries by mapping authenticated Linux users to specific SELinux security contexts, ensuring that their identity dictates their system-wide privileges regardless of the application they use.

The SELinux User Mapping Concept

By default, SELinux assigns a generic unconfined_u user to most Linux accounts. However, in a hardened environment, we want to restrict what a user can execute based on their authenticated identity. SELinux user mapping acts as a secondary layer of authorization: even if a user is valid in your system or LDAP/SSSD, SELinux will force them into a specific, limited security domain (or "role") at the kernel level.

Defining the Mapping

To map an existing Linux user to an SELinux user, we use the semanage login command. This creates a rule that associates the user’s login name with a predefined SELinux identity, which carries its own set of rules regarding which domains (such as user_u, staff_u, or sysadm_u) the user can enter.

For example, to map a user named contractor to the restricted user_u domain, you would execute:

# Map user to the confined user_u identity
sudo semanage login -a -s user_u contractor

# Apply the changes to the system
sudo restorecon -R -v /home/contractor

Why This Matters

When a user logs in, the PAM stack authenticates their credentials (as you learned in previous lessons), and SELinux then checks the mapping database. If contractor attempts to run a binary or access a file that is not permitted under the user_u context, the kernel will block the action, even if the traditional Linux file permissions (UGO) allow it.

This is particularly useful when managing administrative access; you might map a standard user to user_u (who cannot run administration commands) and a sysadmin to staff_u (who can transition to sysadm_t via sudo). By decoupling the Linux account from the SELinux identity, you gain granular control over what a user can "be" inside the operating system, rather than just what they "own."

Key Takeaway: SELinux user mapping bridges the gap between identity authentication and mandatory access control, forcing users into restrictive security domains defined by their login identity.