SELinux Access Workflow

The flow below essentially depicts how SELinux controls access between processes and files.

SELinux Access Control Decision Workflow

1. Linux Security Module Subsystem:

   • When a process (in our case, the Apache HTTP server) tries to access a resource (a file, for example), the Linux kernel will consult the Linux Security Module (LSM) subsystem.
   • The LSM will forward this decision to SELinux if SELinux is enabled and enforcing.

2. SELinux Policy: The SELinux policy defines rules about who can access what. The policy example given here:

allow httpd_t httpd_sys_content:file(read write)

This means: Processes labeled with the SELinux type httpd_t are allowed to read and write files labeled with httpd_sys_content_t.

3. Process and File Labels:

• The Apache HTTP server binary (/usr/sbin/httpd) is running as a process labeled httpd_t.
• The example HTML file (like /var/www/html/index.html) have an SELinux file type label of httpd_sys_content_t.

4. Contexts:

• Everything under SELinux has a context. This context is a label that consists of the SELinux user, role, type, and (optionally) a level. In the provided info:
  • The process (/usr/sbin/httpd) has a context of system_u:system_r:httpd_t:s0
  • The example HTML file (/var/www/html/index.html) have a context of system_u:object_r:httpd_sys_content_t:s0

5. Decision Flow:

• When the Apache HTTP server (labeled httpd_t) tries to write to (or read from) the example HTML file (labeled httpd_sys_content_t), SELinux checks the policy.
• If the policy has an “allow” rule, like the one provided, the access will be permitted.
• If no such rule exists, the access will be denied, even if standard Linux permissions (like file owner/group and permission bits) allow it.

Here is Sequence Diagram of the above flow.

  sequenceDiagram
    participant Process as Process<br/>(/usr/sbin/httpd)
    participant Resource as Resource<br/>(/var/www/html/index.html)
    participant Kernel as Linux<br/>Kernel
    participant LSM as LSM<br/>Subsystem
    participant SELinux as SELinux
    participant Policy as SELinux<br/>Policy
    Process->>Kernel: Request to access Resource
    Kernel->>LSM: Forward access request
    LSM->>SELinux: Direct request for decision
    SELinux->>SELinux: Retrieve Process context
    Note right of SELinux: Process context:<br/>(system_u:system_r:httpd_t:s0)
    SELinux->>SELinux: Retrieve Resource context
    Note right of SELinux: Resource context:<br/>(system_u:object_r:httpd_sys_content_t:s0)
    SELinux->>Policy: Consult policy for access decision
    Policy->>SELinux: Return decision
    Note right of Policy: Decision:<br/>(allow httpd_t httpd_sys_content:file(read write))
    SELinux->>Process: Grant/Deny access based on policy decision
    Process->>Resource: Access Resource

In Summary:

1. SELinux is like a security guard who checks a predefined rulebook and makes a decision to allow or deny a person access to a room in a building.
2. When the Apache server (a person in this analogy) tries to access the HTML files (a room in a building), the guard checks if this person has permission in the rulebook.
3. If the rulebook says “yes”, the person can access the room. If not, they can’t.