From SELinux Wiki
Jump to: navigation, search


The SELinux user is not equivalent to a Linux user. One significant difference between the SELinux users and Linux users is SELinux users do not change during a user session, whereas a Linux user might change via su or sudo. Typically many Linux users will use the same SELinux user, but it is possible to have a 1:1 Linux user to SELinux user mapping, such as the root Linux user and the root SELinux user. By convention, SELinux users that are generic have the suffix "_u", such as user_u.


A SELinux user may be allowed to take on one or more roles. What a role means is defined by the policy, but examples of roles are an unprivileged user, a web administrator, and a database administrator. Objects typically have the role object_r. By convention, roles have the suffix "_r", such as user_r.


This is the primary means of determining access (this will be further discussed later). The type of a process is also referred to as its domain. By convention, a type has the suffix "_t", such as user_t.


Every process and object in the system has a context (also known as a label). This is an attribute used to determine if an access should be allowed between a process and an object. For example, a user process might have the context of user_u:user_r:user_t, and file in the user's home directory might have the context user_u:object_r:user_home_t. A SELinux context consists of three required fields, and one optional field:


The first field is the SELinux user. The second field is the role. The third field in the type. The forth field is the MLS range; this field is optional, and will be discussed later. The following is an example context:


In this context, the user is system_u, the role is system_r, and the type is xserver_t. The following is an example context, with the MLS field:


If MLS translations are enabled, the above context might instead be:


Object Classes

SELinux has many object classes (categories of objects), such as dir for directories and file for files. These are used in the policy and in access decisions to more finely specify what access is allowed. Each object class has a set of permissions which are the possible ways to access these objects. For example, the file object class has the permissions create, read, write, and unlink (delete), while the unix_stream_socket object class (UNIX domain stream sockets) has the permissions create, connect, and sendto. See ObjectClassesPerms for a complete listing of object classes and their permissions.


The primary security mechanism of SELinux is type enforcement, meaning that rules are specified using the type of the process and object:

allow user_t user_home_t:file { create read write unlink };

This rule states that the user_t type is allowed to create, read, write, and delete files with the user_home_t type. More information on adding rules to the policy will be covered in other pages.