Introduction to Android SELinux and MAC Hardening

Android’s security model heavily relies on Mandatory Access Control (MAC) through SELinux (Security-Enhanced Linux) to protect system resources and user data. Unlike Discretionary Access Control (DAC), where owners decide permissions, MAC enforces system-wide policies, preventing even root users from performing unauthorized actions if the policy denies it. This article delves into advanced techniques for exploiting SELinux policy weaknesses and, critically, how to patch and harden Android systems against such bypasses.

Understanding SELinux on Android is paramount for both penetration testers and system developers. It ensures critical system services, device drivers, and core applications operate within strictly defined boundaries, limiting the blast radius of any successful exploit.

Understanding Android SELinux Policy Architecture

SELinux Fundamentals

At its core, SELinux operates on a type enforcement (TE) model. Every file, process, and system resource (objects) is labeled with an SELinux context, which consists of a user, role, type, and sensitivity. On Android, the type is the most critical component. Policy rules then dictate how types can interact with each other.

• Subjects: Processes (e.g., app_process, system_server).
• Objects: Files, directories, sockets, IPC, devices.
• Types (Domains): Labels applied to processes (domains) and objects (types). For instance, untrusted_app is a domain, while app_data_file is a type.
• Permissions: Specific actions (e.g., read, write, execute, bind).
• Rules: allow source_type target_type:class perm_set;

The Android SELinux policy is compiled from .te (type enforcement) files into a binary sepolicy file, which is loaded at boot. You can inspect the current enforcement mode:

adb shell getenforce

To view the SELinux contexts of processes and files:

adb shell ps -Zadb shell ls -Z /data/data/com.example.app

Detecting Policy Weaknesses with Audit Logs

When an action is denied by SELinux, an Access Vector Cache (AVC) denial is logged by the kernel. These audit messages are invaluable for identifying policy gaps or potential exploit paths. They typically appear in dmesg or logcat, and can be aggregated by auditd if enabled.

adb shell su -c 'dmesg | grep

        
        
        

            

                
            
            

                
Android Mobile Specs & Compare Directory
                
Are you researching mobile hardware properties, processor SoCs, GPU chipsets, or RAM configurations? Access our complete specs catalog to compare up to 5 devices side-by-side!
                Compare Devices Specs →