Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

4.3. Confined and Unconfined Users

Each Linux user is mapped to an SELinux user via 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 the Linux root user:
# /usr/sbin/semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023
In Fedora 11, Linux users are mapped to the SELinux __default__ login by default (which is mapped to the SELinux unconfined_u user). The following defines the default-mapping:
__default__               unconfined_u              s0-s0:c0.c1023
The following example demonstrates adding a new Linux user, and that Linux user being mapped to the SELinux unconfined_u user. It assumes that the Linux root user is running unconfined, as it does by default in Fedora 11:
  1. As the Linux root user, run the /usr/sbin/useradd newuser command to create a new Linux user named newuser.
  2. As the Linux root user, run the passwd newuser command to assign a password to the Linux newuser user:
    # 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.
    
  3. Log out of your current session, and log in as the Linux newuser user. When you log in, pam_selinux 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 id -Z command to view the context of a Linux user:
    [newuser@localhost ~]$ id -Z
    unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
    
  4. Log out of the Linux newuser's session, and log in with your account. If you do not want the Linux newuser user, run the /usr/sbin/userdel -r newuser command as the Linux root user to remove it, along with the Linux newuser's home directory.
Confined and unconfined Linux users are subject to executable and writeable memory checks, and are also restricted by MCS (and MLS, if the MLS policy is used). If unconfined Linux users execute an application that SELinux policy defines can transition from the unconfined_t domain to its own confined domain, unconfined Linux users are 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, and therefore, the exploitation of a flaw in the application can be limited by policy. Note: this does not protect the system from the user. Instead, the user and the system are being protected from possible damage caused by a flaw in the application.
The following confined SELinux users are available in Fedora 11:
User Domain X Window System su and sudo Execute in home directory and /tmp/ Networking
guest_u guest_t no no optional no
xguest_u xguest_t yes no optional only Firefox
user_u user_t yes no optional yes
staff_u staff_t yes only sudo optional yes
Table 4.1. SELinux User Capabilities

  • Linux users in the guest_t, xguest_t, and user_t domains can only run set user ID (setuid) applications if SELinux policy permits it (such as passwd). They can not run the su and /usr/bin/sudo setuid applications, and therefore, can not use these applications to become the Linux root user.
  • Linux users in the guest_t domain have no network access, and can only log in via a terminal (including ssh; they can log in via ssh, but can not use ssh to connect to another system).
  • The only network access Linux users in the xguest_t domain have is Firefox connecting to web pages.
  • Linux users in the xguest_t, user_t and staff_t domains can log in via the X Window System and a terminal.
  • By default, Linux users in the staff_t domain do not have permissions to execute applications with /usr/bin/sudo. These permissions must be configured by an administrator.
By default, Linux users in the guest_t and xguest_t domains can not execute applications in their home directories or /tmp/, 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 files users' own.
By default, Linux users in the user_t and staff_t domains can execute applications in their home directories and /tmp/. Refer to Section 6.6, “Booleans for Users Executing Applications” for information about allowing and preventing users from executing applications in their home directories and /tmp/.

 
 
  Published under the terms of the GNU General Public License Design by Interspire