In this lesson, you will learn how Type Enforcement (TE) acts as the fundamental gatekeeper in SELinux by restricting interactions based on strictly defined security types rather than user identity.
Beyond Identity: The Power of Types
In traditional Discretionary Access Control (DAC), permissions are based on "who" you are (user/group). In contrast, Mandatory Access Control uses Type Enforcement. Here, every process is assigned a "domain" (a type for an active process), and every object—such as a file, socket, or device—is assigned a "type."
The core philosophy of TE is simple: a process can only perform an action on an object if a specific rule in the loaded security policy explicitly allows that interaction between those two specific types. It doesn't matter if the user is root; if the policy doesn't authorize the httpd_t domain to read from user_home_t, the kernel will block the access.
How Interactions are Defined
Think of TE as a grid of allowed permissions. A policy rule essentially reads like a conversation between two entities:
allow httpd_t var_log_t:file { read append };
In this example, the process type httpd_t (the web server) is permitted to perform a read or append operation on any object with the var_log_t type. Crucially, if you were to try to write to a file labeled etc_t (system configuration), the kernel checks the policy, finds no rule permitting httpd_t to interact with etc_t, and denies the request immediately.
This granularity is the cornerstone of system hardening. Because the rules are defined by the policy and not by individual users or file owners, even a compromised service with high privileges remains trapped within its own "domain cage." It cannot interact with any part of the system that hasn't been explicitly pre-approved by the policy author. TE ensures that security is baked into the interaction itself, making the system's security posture predictable and immutable regardless of how files or users are configured on the disk.
Key Takeaway: Type Enforcement mandates that subjects and objects can only interact when an explicit policy rule bridges their respective security types, effectively preventing unauthorized access regardless of user privileges.