Security context

The SELinux security context of passwd(1), as shown by the command:
ls -Z /usr/bin/passwd

A security context (also known as a security label or a domain when referring to processes), is the mechanism used by SELinux to classify resources, such as processes and files, on a SELinux-enabled system. This context allows SELinux to enforce rules for how and by whom a given resource should be accessed. A security context is typically shown as a string consisting of three or four words. Each word specifies a different component of the security context, namely the user, role, type, and level of that file or process. Each word is separated by a colon.

The security context for files is stored in the form of a extended file attribute. A file's security context may be viewed using ls(1) with the -Z option. It may be modified using chcon(1), whose syntax is intentionally similar to chmod. A file's security context is associated with the file's inode and not the location or directory; this ensures that security contexts will remain the same regardless of whether a file is moved or renamed.

Some filesystems do not support support extended file attributes. In these cases, the kernel provides a default security context for that filesystem. For example, all files on an NFS filesystem are labeled "system_u:object_r:nfs_t".

Fields

The security context is comprised of four fields: user, role, type, and level. All fields are required, except for the level.

User field

The first component of the security context is the "SELinux User" component. This component can be thought of as a way of grouping roles. SELinux Users can have multiple roles that they can reach, and then in those roles they can reach multiple types. Three users that you will usually see on the system are "user_u", "system_u" and root. The user_u is the default SELinux User for a logged in user on a system. "system_u" is the default User for processes started during the boot up process. IE they were never started by a user. "root" is the SELinux user that you get when you login at the console as "root". In targeted policy the user component is really not important. It is more important in MLS and Strict policy machines. On a file the user component specifies the SELinux user that created the file. On the initial system files are labeled as system_u. Or if you relabel they will get set back to system_u. By convention all default SELinux Users end with a "_u" except for root. Originally if you wanted to map a Linux User to an SELinux user, you would create a SELinux user name with the same name as the Linux User. This is why the root user does not end in a "_u". In newer versions of SELinux we have added a mapping file "seusers" which allows you to map Linux Users to SELinux Users without having to create a lot of new SELinux Users.

Role field

The second component of the security context is the Role field. This field is only really relevant on processes or domains. The role field on a file is always object_r, and really has no meaning other than as a place holder. On a process you would usually see a role like system_r or sysadm_r. Roles are used to group security types. So you can specify in policy which roles are able to execute which types. This is the basis of "Roles Based Access Control" (RBAC) in SELinux. RBAC is not really used in targeted policy, but becomes more important in Strict and MLS policy. MLS Policy also contains sysadm_r, staff_r, and secadm_r. Roles by convention end with a "_r".

Type field

The 3rd component of the security context is the Type component, for example /usr/sbin/httpd is labeled with a type of “httpd_exec_t".

In my opinion this is the most important field in the SELinux security context. This is the heart of SELinux Type Enforcement. Most of the policy rules in SELinux revolve around what subject types have what access to which object types. By convention this component always ends in a "_t".

Level field

The 4th component is the MLS, or Multilevel security, field which is not supported in RHEL4 or Fedora Core 4. It is first showing up with Fedora Core 5, although it has been in SELinux in the previous versions, it was never turned on.

This component is used in all policies shipped with Fedora Core 5. On strict and targeted policies we refer to this as the MCS (Multi Category System) Field. Unfortunately this field can contain a ":". The syntax of this field can look something like s0-s15:c1,c2. But I will put off talking about this syntax until a later date. Most files by default are labeled s0, sometimes referred to as SystemLow. Fortunately SELinux provides a translation library (libsetrans) that replaces the codes in this field with a more human readable form. So something like s0:c1,c2 might be show up to the user as PatientRecord,CompanyConfidential. On a targeted or strict policy machine s0 translates to "", so almost all files will not even show the fourth field.

Advanced

The method used by SELinux to associate security contexts with inodes is also used by DAC protections and ACL's.