BasicConcepts

From SELinux Wiki
Revision as of 15:21, 29 October 2009 by ChrisPeBenito (Talk | contribs)

Jump to: navigation, search

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 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 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.

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".

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.

The forth field is the MLS range. This field optional, and will be discussed later.

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.