10.3.3. Confined and Unconfined Users

⁠10.3.3. 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. This Linux user mapping is seen by running 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       *
system_u             system_u             s0-s0:c0.c1023       *

In Fedora, 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

The following procedure demonstrates how to add a new Linux user to the system and how to map that user to the SELinux unconfined_u user. It assumes that the root user is running unconfined, as it does by default in Fedora:

⁠

Procedure 10.6. Mapping a New Linux User to the SELinux unconfined_u User

As root, run the following command to create a new Linux user named newuser:
```
~]# useradd newuser
```

To assign a password to the Linux newuser user. Run the following command as root:

~]# passwd newuser
Changing password for user newuser.
New UNIX password: Enter a password 
Retype new UNIX password: Enter the same password again 
passwd: all authentication tokens updated successfully.

Log out of your current session, and log in as the Linux newuser 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. Run the following command to view the context of a Linux user:
```
[newuser@localhost ~]$ id -Z 
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
```
Note
If you no longer need the newuser user on your system, log out of the Linux newuser's session, log in with your account, and run the userdel -r newuser command as root. It will remove newuser along with their home directory.

Confined and unconfined Linux users are subject to executable and writeable memory checks, and are also restricted by MCS or MLS.

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. However, each confined Linux user is restricted by a confined user domain against the unconfined_t 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 Linux 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. In the table below, you can see examples of basic confined domains for Linux users in Fedora:

⁠

Table 10.1. SELinux User Capabilities

User	Domain	X Window System	su or sudo	Execute in home directory and /tmp/ (default)	Networking
sysadm_u	sysadm_t	yes	su and sudo	yes	yes
staff_u	staff_t	yes	only sudo	yes	yes
user_u	user_t	yes	no	yes	yes
guest_u	guest_t	no	no	no	yes
xguest_u	xguest_t	yes	no	no	Firefox only

Linux users in the user_t, guest_t, xguest_t, and git_shell_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 via the X Window System and a terminal.
By default, Linux users in the guest_t and xguest_t domains cannot execute applications in their home directories or the /tmp/ directory, preventing them from executing applications, which inherit users' permissions, in directories they have write access to. This helps prevent flawed or malicious applications from modifying users' files.
By default, Linux users in the staff_t and user_t domains can execute applications in their home directories and /tmp/. See Section 10.6.6, “Booleans for Users Executing Applications” for information about allowing and preventing users from executing applications in their home directories and /tmp/.
The only network access Linux users in the xguest_t domain have is Firefox connecting to web pages.