What are the components of an SELinux context and how do you read them?
A context is four colon-separated labels — user:role:type:level (e.g. unconfined_u:object_r:httpd_sys_content_t:s0) — and in the everyday "targeted" policy the TYPE is the one that actually drives access decisions.
* Anatomy of an SELinux context — type is what access checks compare. *
Every process and every file wears one of these labels, and policy rules are written almost entirely in terms of type vs type (this is called Type Enforcement). The other three fields matter in specialised setups: the SELinux user and role support role-based access for confined logins (MLS/RBAC), and the level (s0, s0-s15:c0.c1023…) is for Multi-Level Security clearances. But for the common case — "may this process read that file?" — you compare the two *_t types.
unconfined_u:object_r:httpd_sys_content_t:s0
| | | |
SELinux Role Type Level
User (most important)
| Component | Purpose | Example |
|---|---|---|
| User | SELinux user identity | system_u, unconfined_u |
| Role | Role-based access control | system_r, object_r |
| Type | Primary access control | httpd_t, httpd_sys_content_t |
| Level | Multi-Level Security (MLS) | s0 |
Type is most important for targeted policy!
Example - Apache web server:
- Process type:
httpd_t - Web content type:
httpd_sys_content_t - SELinux allows
httpd_tto readhttpd_sys_content_t
Cross-access blocked:
- Apache (
httpd_t) cannot access MySQL data (mysqld_db_t) - MySQL (
mysqld_t) cannot access web content (httpd_sys_content_t)
Go deeper:
Type enforcement (Wikipedia) — why the *_tTYPE field drives access decisions in the targeted policy.