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

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

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.

2.10. SELinux Users and Roles

Important Important
 

Users and roles can play a part in an SELinux policy. However, the greater part of SELinux is Type Enforcement. Additionally, the targeted policy is designed not to utilize users and roles. Every domain in the targeted policy runs in a single role, and TE is used to separate the confined processes from the other processes.

This is why, when discussing interaction of processes and files, the type component is what you focus on.

2.10.1. SELinux Roles

Roles define which SELinux user identities can have access to what domains. Roles are created by the existence of one or more declarations in a TE rules file in $SELINUX_SRC/domains/*:

Simply being in a role is not enough to allow domain transition. If a process is in role_r and domain1_t, and role_r is authorized for domain2_t, the process cannot jump to domain2_t. There must be an allow rule for the process transition to take place.

For example, the domains named_t and squid_t are both in the role system_r. However, named_t cannot transition to squid_t without an allow rule.

This shows the syntax and an allow example for role:

# syntax for role declaration

role <rolename> types <domain(s)>;

# example of role declaration from 
# $SELINUX_SRC/domains/programs/ldconfig.te

role sysadm_r types ldconfig_t;
/* administrators are allowed access to ldconfig_t domain */


# syntax for role allow

allow <current_role(s)> <new_role(s)>;

# example of role allow from $SELINUX_SRC/rbac

allow user_r sysadm_r;

Grouping domains into roles is relatively intuitive, since roles are task-oriented[1]. Every process has a role, starting with the system role, system_r. Users gain a role at login, which includes using su where a new role can come with the new UID, or you can keep your UID and change your role using newrole; however, this is not often done. Domains are changed often and quietly, but roles rarely change, especially under the targeted policy. Another way to change roles is through a role_transition, this is also very rare and currently only used for an administrative role to launch daemons in a different role under a stricter policy:

role_transition sysadm_r $1_exec_t system_r;
/* When an administrator executes a process with the type of */
/* $1_exec_t, the process transitions from sysadm_r to       */
/* system_r.                                                 */

2.10.2. SELinux Users

SELinux user identities are different from UNIX identities. They are applied as part of the security label and can be changed in real time under limited conditions. SELinux identities are not primarily used in the targeted policy. In the targeted policy, processes and objects are system_u, and the default for Linux users is user_u. When identities are part of the policy scheme, they are usually identical to the Linux account name (UID), and are compiled into the policy. In such a strict policy, some system accounts may run under a generic, unprivileged user_u identity, while other accounts have direct identities in the policy database.[2]

For a review of the roles and users, including a discussion of the $SELINUX_SRC/users file, refer to Section 3.5 Understanding the Roles and Users in the Targeted Policy.

Notes

[1]

Roles can encompass other roles, inheriting the privileges of the included role. This dominance capability is not used in the targeted policy. This syntax example shows a role that is declared to dominate over, and inherit the privileges of, sysadm_r and user_r:

dominance {role master_r {role sysadm_r; role user_r;} }
[2]

Linux UIDs and SELinux user identities should match because login and similar applications will try to look up the match. If it fails to find a match, it will fall back to user_u.

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