Chapter 3. Managing confined and unconfined users Each Linux user is mapped to an SELinux user according to the rules in the SELinux policy. Administrators can modify these rules by using the semanage login utility or by assigning Linux users directly to specific SELinux users. Therefore, a Linux user has the restrictions of the SELinux user to which it is assigned. When a Linux user that is assigned to an SELinux user launches a process, this process inherits the SELinux user's restrictions, unless other rules specify a different role or type. 3.1. Confined and unconfined users in SELinux By default, all Linux users in Red Hat Enterprise Linux, including users with administrative privileges, are mapped to the unconfined SELinux user unconfined_u . You can improve the security of the system by assigning users to SELinux confined users. The security context for a Linux user consists of the SELinux user, the SELinux role, and the SELinux type. For example: Where: user_u Is the SELinux user. user_r Is the SELinux role. user_t Is the SELinux type. After a Linux user logs in, its SELinux user cannot change. However, its type and role can change, for example, during transitions. To see the SELinux user mapping on your system, use the semanage login -l command as root: In Red Hat Enterprise Linux, Linux users are mapped to the SELinux __default__ login by default, which is mapped to the SELinux unconfined_u user. The following line defines the default mapping: Confined users are restricted by SELinux rules explicitly defined in the current SELinux policy. Unconfined users are subject to only minimal restrictions by SELinux. Confined and unconfined Linux users are subject to executable and writable memory checks, and are also restricted by MCS or MLS. To list the available SELinux users, enter the following command: Note that the seinfo command is provided by the setools-console package, which is not installed by default. If an unconfined Linux user executes an application that SELinux policy defines as one that can transition from the unconfined_t domain to its own confined domain, the unconfined Linux user is still subject to the restrictions of that confined domain. The security benefit of this is that, even though a Linux user is running unconfined, the application remains confined. Therefore, the exploitation of a flaw in the application can be limited by the policy. Similarly, we can apply these checks to confined users. Each confined user is restricted by a confined user domain. The SELinux policy can also define a transition from a confined user domain to its own target confined domain. In such a case, confined users are subject to the restrictions of that target confined domain. The main point is that special privileges are associated with the confined users according to their role. 3.2. Roles and access rights of SELinux users The SELinux policy maps each Linux user to an SELinux user. This allows Linux users to inherit the restrictions of SELinux users. You can customize the permissions for confined users in your SELinux policy according to specific needs by adjusting booleans in the policy. You can determine the current state of these booleans by using the semanage boolean -l command. To list all SELinux users, their SELinux roles, and levels and ranges for MLS and MCS, use the semanage user -l command as root . Table 3.1. Roles of SELinux users User Default role Additional roles unconfined_u unconfined_r system_r guest_u guest_r xguest_u xguest_r user_u user_r staff_u staff_r sysadm_r unconfined_r system_r sysadm_u sysadm_r root staff_r sysadm_r unconfined_r system_r system_u system_r Note that system_u is a special user identity for system processes and objects, and system_r is the associated role. Administrators must never associate this system_u user and the system_r role to a Linux user. Also, unconfined_u and root are unconfined users. For these reasons, the roles associated to these SELinux users are not included in the following table Types and access rights of SELinux roles . Each SELinux role corresponds to an SELinux type and provides specific access rights. Table 3.2. Types and access rights of SELinux roles Role Type Log in using X Window System su and sudo Execute in home directory and /tmp (default) Networking unconfined_r unconfined_t yes yes yes yes guest_r guest_t no no yes no xguest_r xguest_t yes no yes web browsers only (Mozilla Firefox, GNOME Web) user_r user_t yes no yes yes staff_r staff_t yes only sudo yes yes auditadm_r auditadm_t yes yes yes dbadm_r dbadm_r yes yes yes logadm_r logadm_t yes yes yes webadm_r webadm_r yes yes yes secadm_r secadm_t yes yes yes sysadm_r sysadm_t only when the xdm_sysadm_login boolean is on yes yes yes For more detailed descriptions of the non-administrator roles, see Confined non-administrator roles in SELinux . For more detailed descriptions of the administrator roles, see Confined administrator roles in SELinux . To list all available roles, enter the seinfo -r command: Note that the seinfo command is provided by the setools-console package, which is not installed by default. Additional resources seinfo(1) , semanage-login(8) , and xguest_selinux(8) man pages installed with the selinux-policy-doc package How to modify SELinux settings with booleans 3.3. Confined non-administrator roles in SELinux In SELinux, confined non-administrator roles grant specific sets of privileges and permissions for performing specific tasks to the Linux users assigned to them. By assigning separate confined non-administrator roles, you can assign specific privileges to individual users. This is useful in scenarios with multiple users who each have a different level of authorizations. You can also customize the permissions of SELinux roles by changing the related SELinux booleans on your system. To see the SELinux booleans and their current state, use the semanage boolean -l command as root. You can get more detailed descriptions if you install the selinux-policy-devel package. Linux users in the user_t , guest_t , and xguest_t domains can only run set user ID ( setuid ) applications if SELinux policy permits it (for example, passwd ). These users cannot run the setuid applications su and sudo , and therefore cannot use these applications to become root. By default, Linux users in the staff_t , user_t , guest_t , and xguest_t domains can execute applications in their home directories and /tmp . Applications inherit the permissions of the user that executed them. To prevent guest_t , and xguest_t users from executing applications in directories in which they have write access, set the guest_exec_content and xguest_exec_content booleans to off . SELinux has the following confined non-administrator roles, each with specific privileges and limitations: guest_r Has very limited permissions. Users assigned to this role cannot access the network, but can execute files in the /tmp and /home directories. Related boolean: xguest_r Has limited permissions. Users assigned to this role can log into X Window, access web pages by using network browsers, and access media. They can also execute files in the /tmp and /home directories. Related booleans: user_r Has non-privileged access with full user permissions. Users assigned to this role can perform most actions that do not require administrative privileges. Related booleans: staff_r Has permissions similar to user_r and additional privileges. In particular, users assigned to this role are allowed to run sudo to execute administrative commands that are normally reserved for the root user. This changes roles and the effective user ID (EUID) but does not change the SELinux user. Related booleans: Additional resources To map a Linux user to staff_u and configure sudo , see Confining an administrator using sudo and the sysadm_r role . For additional information about each role and the associated types, see the relevant man pages installed with the selinux-policy-doc package: guest_selinux(8) , xguest_selinux(8) , user_selinux(8) , and staff_selinux(8) 3.4. Confined administrator roles in SELinux In SELinux, confined administrator roles grant specific sets of privileges and permissions for performing specific tasks to the Linux users assigned to them. By assigning separate confined administrator roles, you can divide the privileges over various domains of system administration to individual users. This is useful in scenarios with multiple administrators, each with a separate domain. You can assign these roles to SELinux users by using the semanage user command. SELinux has the following confined administrator roles: auditadm_r The audit administrator role allows managing processes related to the Audit subsystem. Related boolean: dbadm_r The database administrator role allows managing MariaDB and PostgreSQL databases. Related booleans: logadm_r The log administrator role allows managing logs, specifically, SELinux types related to the Rsyslog logging service and the Audit subsystem. Related boolean: webadm_r The web administrator allows managing the Apache HTTP Server. Related booleans: secadm_r The security administrator role allows managing the SELinux database. Related booleans: sysadm_r The system administrator role allows doing everything of the previously listed roles and has additional privileges. In non-default configurations, security administration can be separated from system administration by disabling the sysadm_secadm module in the SELinux policy. For detailed instructions, see Separating system administration from security administration in MLS . The sysadm_u user cannot log in directly using SSH. To enable SSH logins for sysadm_u , set the ssh_sysadm_login boolean to on : Related booleans: Additional resources To assign a Linux user to a confined administrator role, see Confining an administrator by mapping to sysadm_u . For additional information about each role, and the associated types, see the relevant man pages installed with the selinux-policy-doc package: auditadm_selinux(8) , dbadm_selinux (8) , logadm_selinux(8) , webadm_selinux(8) , secadm_selinux(8) , and sysadm_selinux(8) 3.5. Adding a new user automatically mapped to the SELinux unconfined_u user The following procedure demonstrates how to add a new Linux user to the system. The user is automatically mapped to the SELinux unconfined_u user. Prerequisites The root user is running unconfined, as it does by default in Red Hat Enterprise Linux. Procedure Enter the following command to create a new Linux user named <example_user> : To assign a password to the Linux <example_user> user: Log out of your current session. Log in as the Linux <example_user> user. When you log in, the pam_selinux PAM module automatically maps the Linux user to an SELinux user (in this case, unconfined_u ), and sets up the resulting SELinux context. The Linux user's shell is then launched with this context. Verification When logged in as the <example_user> user, check the context of a Linux user: Additional resources pam_selinux(8) man page on your system 3.6. Adding a new user as an SELinux-confined user Use the following steps to add a new SELinux-confined user to the system. This example procedure maps the user to the SELinux staff_u user right with the command for creating the user account. Prerequisites The root user is running unconfined, as it does by default in Red Hat Enterprise Linux. Procedure Enter the following command to create a new Linux user named <example_user> and map it to the SELinux staff_u user: To assign a password to the Linux <example_user> user: Log out of your current session. Log in as the Linux <example_user> user. The user's shell launches with the staff_u context. Verification When logged in as the <example_user> user, check the context of a Linux user: Additional resources pam_selinux(8) man page on your system 3.7. Confining regular users in SELinux You can confine all regular users on your system by mapping them to the user_u SELinux user. By default, all Linux users in Red Hat Enterprise Linux, including users with administrative privileges, are mapped to the unconfined SELinux user unconfined_u . You can improve the security of the system by assigning users to SELinux confined users. This is useful to conform with the V-71971 Security Technical Implementation Guide . Procedure Display the list of SELinux login records. The list displays the mappings of Linux users to SELinux users: Map the __default__ user, which represents all users without an explicit mapping, to the user_u SELinux user: Verification Check that the __default__ user is mapped to the user_u SELinux user: Verify that the processes of a new user run in the user_u:user_r:user_t:s0 SELinux context. Create a new user: Define a password for <example_user> : Log out as root and log in as the new user. Show the security context for the user's ID: Show the security context of the user's current processes: 3.8. Confining an administrator by mapping to sysadm_u You can confine a user with administrative privileges by mapping the user directly to the sysadm_u SELinux user. When the user logs in, the session runs in the sysadm_u:sysadm_r:sysadm_t SELinux context. By default, all Linux users in Red Hat Enterprise Linux, including users with administrative privileges, are mapped to the unconfined SELinux user unconfined_u . You can improve the security of the system by assigning users to SELinux confined users. This is useful to conform with the V-71971 Security Technical Implementation Guide . Prerequisites The root user runs unconfined. This is the Red Hat Enterprise Linux default. Procedure Optional: To allow sysadm_u users to connect to the system by using SSH: Map a new or existing user to the sysadm_u SELinux user: To map a new user, add a new user to the wheel user group and map the user to the sysadm_u SELinux user: To map an existing user, add the user to the wheel user group and map the user to the sysadm_u SELinux user: Restore the context of the user's home directory: Verification Check that <example_user> is mapped to the sysadm_u SELinux user: Log in as <example_user> , for example, by using SSH, and show the user's security context: Switch to the root user: Verify that the security context remains unchanged: Try an administrative task, for example, restarting the sshd service: If there is no output, the command finished successfully. If the command does not finish successfully, it prints the following message: 3.9. Confining an administrator by using sudo and the sysadm_r role You can map a specific user with administrative privileges to the staff_u SELinux user, and configure sudo so that the user can gain the sysadm_r SELinux administrator role. This role allows the user to perform administrative tasks without SELinux denials. When the user logs in, the session runs in the staff_u:staff_r:staff_t SELinux context, but when the user enters a command by using sudo , the session changes to the staff_u:sysadm_r:sysadm_t context. By default, all Linux users in Red Hat Enterprise Linux, including users with administrative privileges, are mapped to the unconfined SELinux user unconfined_u . You can improve the security of the system by assigning users to SELinux confined users. This is useful to conform with the V-71971 Security Technical Implementation Guide . Prerequisites The root user runs unconfined. This is the Red Hat Enterprise Linux default. Procedure Map a new or existing user to the staff_u SELinux user: To map a new user, add a new user to the wheel user group and map the user to the staff_u SELinux user: To map an existing user, add the user to the wheel user group and map the user to the staff_u SELinux user: Restore the context of the user's home directory: To allow <example_user> to gain the SELinux administrator role, create a new file in the /etc/sudoers.d/ directory, for example: Add the following line to the new file: Verification Check that <example_user> is mapped to the staff_u SELinux user: Log in as <example_user> , for example, using SSH, and switch to the root user: Show the root security context: Try an administrative task, for example, restarting the sshd service: If there is no output, the command finished successfully. If the command does not finish successfully, it prints the following message: 3.10. Additional resources unconfined_selinux(8) , user_selinux(8) , staff_selinux(8) , and sysadm_selinux(8) man pages installed with the selinux-policy-doc package on your system How to set up a system with SELinux confined users (Red Hat Knowledgebase) How to modify SELinux settings with booleans (Red Hat Sysadmin)

Commands:
user_u:user_r:user_t
# semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 *
default unconfined_u s0-s0:c0.c1023 *
seinfo -u Users: 8 guest_u root staff_u sysadm_u system_u unconfined_u user_u xguest_u
USD seinfo -r Roles: 14 auditadm_r dbadm_r guest_r logadm_r nx_server_r object_r secadm_r staff_r sysadm_r system_r unconfined_r user_r webadm_r xguest_r
semanage boolean -l SELinux boolean State Default Description ... xguest_connect_network (on , on) Allow xguest users to configure Network Manager and connect to apache ports xguest_exec_content (on , on) Allow xguest to exec content ...
SELinux boolean State Default Description guest_exec_content (on , on) Allow guest to exec content
SELinux boolean State Default Description xguest_connect_network (on , on) Allow xguest users to configure Network Manager and connect to apache ports xguest_exec_content (on , on) Allow xguest to exec content xguest_mount_media (on , on) Allow xguest users to mount removable media xguest_use_bluetooth (on , on) Allow xguest to use blue tooth devices
SELinux boolean State Default Description unprivuser_use_svirt (off , off) Allow unprivileged user to create and transition to svirt domains.
SELinux boolean State Default Description staff_exec_content (on , on) Allow staff to exec content staff_use_svirt (on , on) allow staff user to create and transition to svirt domains.
SELinux boolean State Default Description auditadm_exec_content (on , on) Allow auditadm to exec content
SELinux boolean State Default Description dbadm_exec_content (on , on) Allow dbadm to exec content dbadm_manage_user_files (off , off) Determine whether dbadm can manage generic user files. dbadm_read_user_files (off , off) Determine whether dbadm can read generic user files.
SELinux boolean State Default Description logadm_exec_content (on , on) Allow logadm to exec content
SELinux boolean State Default Description webadm_manage_user_files (off , off) Determine whether webadm can manage generic user files. webadm_read_user_files (off , off) Determine whether webadm can read generic user files.
SELinux boolean State Default Description secadm_exec_content (on , on) Allow secadm to exec content
setsebool -P ssh_sysadm_login on
SELinux boolean State Default Description ssh_sysadm_login (on , on) Allow ssh logins as sysadm_r:sysadm_t sysadm_exec_content (on , on) Allow sysadm to exec content xdm_sysadm_login (on , on) Allow the graphical login program to login directly as sysadm_r:sysadm_t
# useradd <example_user>
# passwd <example_user> Changing password for user <example_user> . New password: Retype new password: passwd: all authentication tokens updated successfully.
id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
# useradd -Z staff_u <example_user>
# passwd <example_user> Changing password for user <example_user> . New password: Retype new password: passwd: all authentication tokens updated successfully.
id -Z uid=1000( <example_user> ) gid=1000( <example_user> ) groups=1000( <example_user> ) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 *
semanage login -m -s user_u -r s0 __default__
semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ user_u s0 * root unconfined_u s0-s0:c0.c1023 *
adduser <example_user>
passwd <example_user>
[ <example_user> @localhost ~]USD id -Z user_u:user_r:user_t:s0
[ <example_user> @localhost ~]USD ps axZ LABEL PID TTY STAT TIME COMMAND - 1 ? Ss 0:05 /usr/lib/systemd/systemd --switched-root --system --deserialize 18 - 3729 ? S 0:00 (sd-pam) user_u:user_r:user_t:s0 3907 ? Ss 0:00 /usr/lib/systemd/systemd --user - 3911 ? S 0:00 (sd-pam) user_u:user_r:user_t:s0 3918 ? S 0:00 sshd: <example_user> @pts/0 user_u:user_r:user_t:s0 3922 pts/0 Ss 0:00 -bash user_u:user_r:user_dbusd_t:s0 3969 ? Ssl 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only user_u:user_r:user_t:s0 3971 pts/0 R+ 0:00 ps axZ
setsebool -P ssh_sysadm_login on
adduser -G wheel -Z sysadm_u <example_user>
usermod -G wheel -Z sysadm_u <example_user>
restorecon -R -F -v /home/ <example_user>
semanage login -l | grep <example_user> <example_user> sysadm_u s0-s0:c0.c1023 *
[ <example_user> @localhost ~]USD id -Z sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
sudo -i [sudo] password for <example_user> :
id -Z sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
systemctl restart sshd
Failed to restart sshd.service: Access denied See system logs and 'systemctl status sshd.service' for details.
adduser -G wheel -Z staff_u <example_user>
usermod -G wheel -Z staff_u <example_user>
restorecon -R -F -v /home/ <example_user>
visudo -f /etc/sudoers.d/ <example_user>
<example_user> ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL
semanage login -l | grep <example_user> <example_user> staff_u s0-s0:c0.c1023 *
[ <example_user> @localhost ~]USD sudo -i [sudo] password for <example_user> :
id -Z staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
systemctl restart sshd
Failed to restart sshd.service: Access denied See system logs and 'systemctl status sshd.service' for details.