Chapter 3. Managing confined and unconfined users

The following sections explain the mapping of Linux users to SELinux users, describe the basic confined user domains, and demonstrate mapping a new user to an SELinux user.

3.1. Confined and unconfined users

Each Linux user is mapped to an SELinux user using SELinux policy. This allows Linux users to inherit the restrictions on SELinux users.

To see the SELinux user mapping on your system, use the semanage login -l command as root:

# 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       *

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:

__default__          unconfined_u         s0-s0:c0.c1023       *

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:

$ seinfo -u
Users: 8
   guest_u
   root
   staff_u
   sysadm_u
   system_u
   unconfined_u
   user_u
   xguest_u

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. SELinux user capabilities

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 the booleans in the policy. You can determine the current state of these booleans by using the semanage boolean -l command.

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 of SELinux roles.

Each SELinux role corresponds to an SELinux type and provides specific access rights.

Table 3.2. Types and access 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 (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
`secadm_r`	`secadm_t`		yes	yes	yes
`sysadm_r`	`sysadm_t`	only when the `xdm_sysadm_login` boolean is `on`	yes	yes	yes

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 su and sudo setuid applications, and therefore cannot use these applications to become root.
Linux users in the sysadm_t, staff_t, user_t, and xguest_t domains can log in using the X Window System and a terminal.
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.
To prevent them from executing applications, which inherit users' permissions, in directories they have write access to, set the guest_exec_content and xguest_exec_content booleans to off. This helps prevent flawed or malicious applications from modifying users' files.
The only network access Linux users in the xguest_t domain have is Firefox connecting to web pages.
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:
```
# setsebool -P ssh_sysadm_login on
```

Alongside with the already mentioned SELinux users, there are special roles, that can be mapped to those users using the semanage user command. These roles determine what SELinux allows the user to do:

webadm_r can only administrate SELinux types related to the Apache HTTP Server.
dbadm_r can only administrate SELinux types related to the MariaDB database and the PostgreSQL database management system.
logadm_r can only administrate SELinux types related to the syslog and auditlog processes.
secadm_r can only administrate SELinux.
auditadm_r can only administrate processes related to the Audit subsystem.

To list all available roles, enter the the seinfo -r command:

$ 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

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

3.3. 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:
```
# useradd example.user
```

To assign a password to the Linux example.user user:

# passwd example.user
Changing password for user example.user.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

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:
```
$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
```

Additional resources

pam_selinux(8) man page.

3.4. 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:
```
# useradd -Z staff_u example.user
```

To assign a password to the Linux example.user user:

# passwd example.user
Changing password for user example.user.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

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:

$ 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

Additional resources

pam_selinux(8) man page.

3.5. Confining regular users

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:

# 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       *

Map the __default__ user, which represents all users without an explicit mapping, to the user_u SELinux user:
```
# semanage login -m -s user_u -r s0 __default__
```

Verification

Check that the __default__ user is mapped to the user_u SELinux user:

# semanage login -l

Login Name    SELinux User   MLS/MCS Range    Service

__default__   user_u         s0               *
root          unconfined_u   s0-s0:c0.c1023   *

Verify that the processes of a new user run in the user_u:user_r:user_t:s0 SELinux context.

Create a new user:
```
# adduser example.user
```
Define a password for example.user:
```
# passwd example.user
```
Log out as root and log in as the new user.

Show the security context for the user’s ID:

[example.user@localhost ~]$ id -Z
user_u:user_r:user_t:s0

Show the security context of the user’s current processes:

[example.user@localhost ~]$ 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

3.6. 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.

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 using SSH:
```
# setsebool -P ssh_sysadm_login on
```
Create a new user, add the user to the wheel user group, and map the user to the sysadm_u SELinux user:
```
# adduser -G wheel -Z sysadm_u example.user
```
Optional: Map an existing user to the sysadm_u SELinux user and add the user to the wheel user group:
```
# usermod -G wheel -Z sysadm_u example.user
```

Verification

Check that example.user is mapped to the sysadm_u SELinux user:

# semanage login -l | grep example.user
example.user     sysadm_u    s0-s0:c0.c1023   *

Log in as example.user, for example, using SSH, and show the user’s security context:
```
[example.user@localhost ~]$ id -Z
sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
```

Switch to the root user:

$ sudo -i
[sudo] password for example.user:

Verify that the security context remains unchanged:

# id -Z
sysadm_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

Try an administrative task, for example, restarting the sshd service:
```
# systemctl restart sshd
```
If there is no output, the command finished successfully.
If the command does not finish successfully, it prints the following message:
```
Failed to restart sshd.service: Access denied
See system logs and 'systemctl status sshd.service' for details.
```

3.7. Confining an administrator 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 using sudo, the session changes to the staff_u:sysadm_r:sysadm_t context.

Prerequisites

The root user runs unconfined. This is the Red Hat Enterprise Linux default.

Procedure

Create a new user, add the user to the wheel user group, and map the user to the staff_u SELinux user:
```
# adduser -G wheel -Z staff_u example.user
```
Optional: Map an existing user to the staff_u SELinux user and add the user to the wheel user group:
```
# usermod -G wheel -Z staff_u example.user
```
To allow example.user to gain the SELinux administrator role, create a new file in the /etc/sudoers.d/ directory, for example:
```
# visudo -f /etc/sudoers.d/example.user
```

Add the following line to the new file:

example.user ALL=(ALL) TYPE=sysadm_t ROLE=sysadm_r ALL

Verification

Check that example.user is mapped to the staff_u SELinux user:

# semanage login -l | grep example.user
example.user     staff_u    s0-s0:c0.c1023   *

Log in as example.user, for example, using SSH, and switch to the root user:
```
[example.user@localhost ~]$ sudo -i
[sudo] password for example.user:
```

Show the root security context:

# id -Z
staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023

Try an administrative task, for example, restarting the sshd service:
```
# systemctl restart sshd
```
If there is no output, the command finished successfully.
If the command does not finish successfully, it prints the following message:
```
Failed to restart sshd.service: Access denied
See system logs and 'systemctl status sshd.service' for details.
```

3.8. Additional resources

unconfined_selinux(8), user_selinux(8), staff_selinux(8), and sysadm_selinux(8) man pages
How to set up a system with SELinux confined users

Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

Chapter 3. Managing confined and unconfined users

3.1. Confined and unconfined users

3.2. SELinux user capabilities

3.3. Adding a new user automatically mapped to the SELinux unconfined_u user

3.4. Adding a new user as an SELinux-confined user

3.5. Confining regular users

3.6. Confining an administrator by mapping to sysadm_u

3.7. Confining an administrator using sudo and the sysadm_r role

3.8. Additional resources