Android Security Architecture: A Deep Dive into the Linux Kernel & SELinux

By Security Research Team | Advanced Level

TL;DR: Android's security model rests on four pillars: Linux kernel isolation, SELinux mandatory access control, application sandboxing, and the permission system. This post breaks down each layer with real exploitation scenarios.

1. The Linux Kernel Layer

Every Android app runs as a separate Linux user. When you install an app, the system assigns it a unique User ID (UID). This means app A cannot read app B's files because they run under different UIDs — standard Linux file permissions in action.

$ ps -A | grep app_
u0_a123   1234   567    com.whatsapp
u0_a456   7890   111    com.facebook.katana

The kernel also enforces capabilities. Apps run with CAP_NET_ADMIN stripped, preventing raw socket creation on non-rooted devices. This blocks packet injection from user-space apps.

Exploit Scenario: CVE-2016-5195 (Dirty COW) allowed a local app to gain root through a race condition in the kernel's copy-on-write mechanism. On Android, this broke the entire UID isolation model.

2. SELinux: Mandatory Access Control

Since Android 4.3 (enforcing since 5.0), SELinux enforces a mandatory access control (MAC) policy. Even root processes are confined by SELinux contexts.

u:r:untrusted_app:s0:c123,c456
u:r:system_server:s0
u:r:su:s0          # restricted even for root

The policy defines exactly which domains can access which resources. An untrusted_app context cannot read /data/system_ce/ even with root, because the SELinux policy denies it at the kernel level.

3. Application Sandboxing

Each app runs in its own Dalvik/ART VM instance with separate dex2oat compiled code. Since Android 7.0, apps cannot read each other's /data/data/ directories — even with WorldReadable mode set (deprecated in API 24).

Protection	What It Blocks
ASLR	Return-oriented programming (ROP)
RELRO	GOT overwrite attacks
PIE	Fixed-address code injection
NX	Stack & heap execution

4. Permission System

Runtime permissions (introduced in Android 6.0) require user consent at time of use, not install-time.

• Normal: automatically granted (INTERNET, BLUETOOTH)
• Dangerous: runtime prompt required (CAMERA, LOCATION, RECORD_AUDIO)
• Signature: only apps signed with same certificate (BIND_ACCESSIBILITY_SERVICE)
• Privileged: system apps only (INSTALL_PACKAGES)

5. Verified Boot & Device Attestation

Android Verified Boot (AVB) ensures the integrity of the boot chain: Bootloader → Boot Partition → System Partition → Vendor Partition. Each stage cryptographically verifies the next using dm-verity.

adb shell getprop ro.boot.verifiedbootstate
# Returns: green, yellow, or orange

---

Conclusion

Android's security is defense in depth — no single layer protects everything. The kernel sandbox is strong but vulnerable to privilege escalation. SELinux is comprehensive but bypassable through race conditions.

Tags: #AndroidSecurity #SELinux #KernelExploitation #MobilePentesting