In this lesson, you will learn how to deconstruct the four components of an SELinux security context to understand how the kernel governs system access.
While standard permissions (UGO/ACLs) rely on who you are, SELinux adds a layer of "Mandatory Access Control" that dictates what you are allowed to do based on labels. Every process and file in an SELinux-enabled system carries a security context, typically displayed as four colon-separated fields: user:role:type:range.
The Four Components
1. User (user)
This is the SELinux user identity. It is not necessarily the same as your Linux login (root or bob). It maps your Linux account to an SELinux policy, determining which roles you are authorized to assume.
2. Role (role)
The role acts as a bridge. It defines which domains (types) a user is allowed to enter. For example, a system administrator might have a sysadm_r role, while a web server process uses system_r. This prevents a process from jumping into an unauthorized state.
3. Type (type)
The type is the most critical part for daily administration. It defines the "domain" for processes and the "label" for files. For example, a file might be labeled httpd_sys_content_t. If a process running in the httpd_t domain tries to access that file, the policy checks if httpd_t has permission to read httpd_sys_content_t. If the types don't match or the policy doesn't explicitly allow the transition, access is denied.
4. Range (range)
Used in Multi-Level Security (MLS), this field handles sensitivity labels (like s0 or s0:c0.c1023). In most standard configurations, you will see s0, which represents a single, unclassified level of security.
Concrete Example
If you run ls -Z on a web directory, you might see:
system_u:object_r:httpd_sys_content_t:s0 /var/www/html
Here, the system labels the directory with the httpd_sys_content_t type. The kernel policy effectively says, "Only processes running with the httpd_t domain may interact with this file type." Even if you are root, if your current process context doesn't match the required type, the kernel will block the action.
Key Takeaway: The SELinux security context moves security beyond simple ownership by enforcing strict, typed relationships between processes and objects regardless of the user's privilege level.