Advanced SELinux Constraint Rules

Implement strict constraints that define the global limits of all security interactions.

In this lesson, you will learn how to implement strict global constraints that define the immutable boundaries of all security interactions within an SELinux policy.

Understanding SELinux Constraints

While Type Enforcement (TE) handles "who can do what to which object" via allow rules, Constraints act as an overarching "meta-security" layer. Think of TE rules as the laws of a city, and Constraints as the laws of physics: no matter what permissions you grant in your TE policies, a Constraint can forbid an action entirely if the fundamental security criteria aren't met.

Constraints are defined in the policy using the constraint keyword. They are evaluated at access-check time and work as a boolean logical gate: if the expression evaluates to false, the action is denied, even if an allow rule exists.

Example: Restricting Role Transitions

A common use case for constraints is preventing any process from transitioning to a specific, highly privileged role unless the process is running in a specific, trusted security context.

# Global constraint: Only processes with the 'admin_t' type
# can act on objects labeled with the 'system_data_t' type.
constraint {file dir} { write setattr }
    (u1 == u2) or (t1 == admin_t);

In this snippet:

{file dir}: The classes of objects the constraint applies to.
{write setattr}: The operations being restricted.
(u1 == u2): This enforces "Same User" constraints, ensuring a user can only modify files they own, regardless of the file type.
(t1 == admin_t): This acts as an exception, allowing only the admin_t process type to bypass the "Same User" rule.

Why use them?

You use advanced constraints to harden your system against "policy creep." In complex environments with many custom types, it is easy to accidentally grant an over-permissive role access to sensitive files. Constraints provide a "failsafe" that ignores the complexities of your TE rules to enforce global invariants, such as ensuring that untrusted_t processes can never write to system_t files, effectively creating a hard wall that developers cannot accidentally override with standard allow rules.

Key Takeaway: Constraints serve as the absolute, non-negotiable bedrock of your security policy, acting as a final gatekeeper that can override any permitted TE interaction.