Difference between revisions of "BasicConcepts"

From SELinux Wiki
Jump to: navigation, search
(New page: = SELinux Context = Every process and object in the system has a context (alternatively referred to as a label). This is an attribute used to determine if an access should be allowed betw...)
 
(Rules)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= SELinux Context =
+
= Users =
Every process and object in the system has a context (alternatively referred to 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 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''.
  
The first field is the SELinux user. The SELinux user is not equivalent to a Linux user. 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. 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.  By convention, SELinux users that are generic have the suffix "_u", such as ''user_u''.
+
= Roles =
 +
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''.
  
The second field is the role. 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".
+
= Types =
 +
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''.
  
The third field in the type. 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''.
+
= Contexts =
 +
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 forth field is the MLS range. This field will be discussed later.
+
user:role:type:range
 +
 
 +
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:
 +
 
 +
system_u:system_r:xserver_t
 +
 
 +
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:
 +
 
 +
system_u:system_r:xserver_t:s0-s0:c0.c1023
 +
 
 +
If MLS translations are enabled, the above context might instead be:
 +
 
 +
system_u:system_r:xserver_t:SystemLow-SystemHigh
  
 
= Object Classes =
 
= 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''.
+
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.
 +
 
 +
= Rules =
 +
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.

Latest revision as of 18:35, 19 November 2009

Users

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.

Roles

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.

Types

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.

Contexts

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:

user:role:type:range

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:

system_u:system_r:xserver_t

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:

system_u:system_r:xserver_t:s0-s0:c0.c1023

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

system_u:system_r:xserver_t:SystemLow-SystemHigh

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.

Rules

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.