Android SELinux: Mandatory Access Control Policy Architecture

SELinux is the last line of defense in Android's security model. When UID-based Discretionary Access Control fails — and it inevitably does — Mandatory Access Control ensures a compromised mediaserver or browser renderer cannot pivot to exfiltrate keystore keys or remount system partitions.

Since Android 5.0, SELinux has run in enforcing mode for all domains. Yet most developers treat sepolicy as a black box of opaque denials. Understanding its Type Enforcement architecture, security context labeling, and neverallow guarantees is essential for anyone building HALs, system apps, or custom ROMs.

1. Why DAC Is Insufficient on Android

Traditional Linux DAC assigns ownership and rwx bits to users and groups. On Android, every app gets a unique UID (e.g., u0_a123) and runs in its own sandbox. This isolates apps from each other, but DAC has two fundamental flaws for mobile:

• Root is omnipotent: Any process running as UID 0 bypasses DAC checks entirely. A single exploited setuid binary or kernel flaw grants full device control.
• Permission is discretionary: A compromised app can chmod its own files to be world-readable, leaking sensitive data to colluding malware.

Mandatory Access Control inverts this. The policy is centrally defined, compiled into a binary blob, loaded by the kernel at boot, and cannot be overridden by any userspace process — not even root. This principle aligns closely with modern privacy and tracking prevention models where system-enforced guarantees matter more than app-declared permissions.

2. SELinux Core: Type Enforcement and Beyond

Android SELinux is a Type Enforcement (TE) system with Role-Based Access Control (RBAC) and Multi-Level Security (MLS) largely vestigial. Four concepts govern every decision:

The Security Context

Every subject (process) and object (file, socket, Binder endpoint, property) carries a context: user:role:type:level. On Android this collapses to:

u is always SELinux user, r is role (usually r), s0 is MLS sensitivity. The type (e.g., hal_camera_default, system_file) is the sole driver of TE decisions.

The Allow Rule

Policy is a set of allow rules evaluated by the kernel's LSM hook. Syntax:

If no allow rule matches, access is denied by default — even if DAC would permit it. This default-deny posture is why zero-day exploits like Stagefright were contained: mediaserver was confined to mediaserver domain and could not execute su or write to /data despite running as a privileged UID.

3. Android Enforcement Architecture

Every system call that touches a protected object — open(), ioctl(), binder_transaction — is intercepted. The hook extracts source and target contexts, queries the Access Vector Cache (AVC), and on miss performs a full policy DB lookup. This synchronous check adds ~2–3% overhead, mitigated by the AVC's hashed caching, which is critical for Binder's high-throughput IPC.

4. AOSP Policy Structure in Practice

Since Android 8.0's Treble, policy is split to enforce vendor separation:

• Platform policy — system/sepolicy/public/ (exported types/attributes) and private/ (platform-only rules).
• Vendor policy — device/[vendor]/sepolicy/ may only use types exposed via public or its own vendor_ types. Vendor cannot modify system_server policy directly.

Build-time attributes group types for scalable rules:

Attributes like domain, hal_client, netdomain, and appdomain prevent rule explosion. Instead of 80 duplicate allows, you write one allow appdomain hal_camera_service:service_manager find; and all 60+ app domains inherit it. This is similar to how modular 5G hardware abstractions reuse interfaces — policy reuse reduces audit surface.

File Labeling Pipeline

Labels are not stored in xattrs on most partitions at build time; they are assigned via file_contexts:

At runtime, init restores contexts via restorecon, and each daemon transitions to its domain via type_transition when execve() matches a _exec type.

5. Security Context Assignment: Where Theory Meets init

Context transitions are explicit. A process starts as init (u:r:init:s0). When it executes a binary labeled hal_camera_default_exec, the kernel checks:

For apps, zygote forks and seapp_contexts selects context based on UID, seinfo, and package name:

This is why two apps sharing untrusted_app TE type remain isolated: MLS categories differentiate them. Removing categories (a common vendor mistake when porting) silently breaks isolation while passing naive CTS tests.

6. Comparison: DAC vs. SELinux MAC on Android

The two systems are complementary, not competing. DAC handles user consent — “allow this app to read photos.” MAC handles system integrity — “even if compromised, mediaserver cannot load a kernel module.” For data path protection, see our analysis of VPN protocol security boundaries, which assumes MAC is correctly enforcing tunnel isolation.

7. Neverallow: The Policy About Policy

Android's most powerful innovation is neverallow — assertions that must never become true, checked at compile time with secilc and checkpolicy:

If a vendor adds allow untrusted_app kmem_device:chr_file read;, the build fails. Google's Compatibility Test Suite (CTS) and selinux_policy tests run ~300+ neverallow rules, ensuring Treble compliance. This compile-time guarantee is stronger than any runtime audit — it mathematically prevents whole classes of privilege escalation.

To create a custom HAL safely, replicate the pattern:

8. Debugging Without Disabling

On userdebug builds, denials appear in dmesg and logcat:

This tells you: source needed read on chr_file labeled unlabeled (missing file_contexts), not camera_device. Fix the label, not the rule.

Workflow for engineers:

1. adb shell dmesg | grep avc: | audit2allow -p out/target/product/*/obj/ETC/sepolicy_intermediates/sepolicy to generate candidate allows.
2. Manually verify each allow — audit2allow often suggests over-broad rwx where read open suffices.
3. Test with adb shell setenforce 1 and rebuild; never ship a permissive domain — it violates neverallow and fails CTS.
4. Add userdebug_plat_sepolicy.cil exceptions via permissive hal_camera_default; only temporarily.

Remember that permissive mode is diagnostic, not a fix. A permissive domain logs but does not block, hiding real breakage until production. The hardware analogy is leaving coil shielding disabled during testing: you see better efficiency numbers but ship a device that overheats.

Conclusion

Android SELinux succeeds because it makes security architecture explicit. Every Binder call, every /dev node, every property read must justify itself in policy. For embedded engineers, the payoff is a system where a compromised HAL cannot pivot to modem interfaces, and an exploited app cannot dump credentials — not because exploits are impossible, but because the mandatory policy makes post-exploitation lateral movement computationally prohibited.

Treat sepolicy as code: review it, test it with neverallow, and version it with your hardware. The DAC sandbox gets you app isolation; SELinux MAC gets you device integrity.