Introduction: The Critical Role of SELinux in Android Security

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system implemented in the Linux kernel. On Android, SELinux is paramount, enforcing granular permissions on every process, file, and resource access, thereby significantly mitigating the impact of vulnerabilities and containing potential exploits. Instead of relying solely on discretionary access control (DAC), which only checks user and group IDs, SELinux policies define explicit rules for what subjects (processes) can do to what objects (files, sockets, IPC, etc.), based on their security contexts. Understanding and, more importantly, reverse engineering these policies is a critical skill for security researchers, custom ROM developers, and anyone seeking a deeper insight into Android’s robust security architecture.

Analyzing the SELinux policy allows researchers to identify custom rules introduced by device manufacturers, pinpoint potential over-permissive configurations that could lead to privilege escalation, or understand how specific system services are hardened. It’s the blueprint of an Android device’s operational security, dictating permissible interactions between various system components and applications.

Locating and Extracting SELinux Policy Files

SELinux policies on Android are typically stored in a binary format, but during the boot process, they are loaded into the kernel. The primary policy resides in the boot image, while layered policies (for vendor and ODM partitions) are found in their respective images. To begin reverse engineering, we first need to extract these files from a device or a firmware image.

From a Running Device (Root Required)

If you have a rooted device, you can pull the currently active policy directly from the filesystem:

adb shell su -c "cat /sys/fs/selinux/policy > /data/local/tmp/active_sepolicy"adb pull /data/local/tmp/active_sepolicy .

Vendor and ODM specific policies, often in Common Intermediate Language (CIL) format, are usually found in:

adb pull /vendor/etc/selinux/precompiled_sepolicy.pb .adb pull /vendor/etc/selinux/vendor_sepolicy.cil .adb pull /odm/etc/selinux/odm_sepolicy.cil .

From a Firmware Image

For unrooted devices or offline analysis, you’ll need to extract the policy from firmware images. The main binary policy is typically embedded within the boot.img (or init_boot.img on newer devices). You’ll need tools like unpackbootimg (part of AOSP bootimg tools) or magiskboot to decompress and extract files from the boot image. After unpacking, the binary policy might be found as sepolicy or similar within the extracted ramdisk.

# Example using unpackbootimg (install 'android-sdk-platform-tools' or similar)unpackbootimg -i boot.img -o extracted_bootcd extracted_boot/ramdiskcat sepolicy > /path/to/save/boot_sepolicy.binary

Vendor and ODM CIL files are usually located within vendor.img or product.img (often found at /vendor/etc/selinux/ and /odm/etc/selinux/ respectively within the mounted image).

Understanding SELinux Policy File Formats

Android SELinux policies exist in two primary forms:

• Binary Policy (sepolicy): This is the compiled, kernel-loadable format. It’s highly optimized for performance but is not human-readable without specific tools. This file is what the kernel actually enforces.
• Common Intermediate Language (CIL): This is a human-readable, text-based representation of the policy. CIL files are composed of various policy statements like type, allow, macro, role, etc., and are compiled into the binary format. Android’s policy is modularized, meaning plat_sepolicy.cil (platform policy), vendor_sepolicy.cil (vendor-specific additions), and odm_sepolicy.cil (ODM-specific additions) are layered and then compiled together.

The process of reverse engineering involves taking the binary sepolicy and converting it back into a readable CIL format.

Tools for Disassembly and Analysis

Several crucial tools facilitate SELinux policy analysis:

• checkpolicy: A core SELinux utility, primarily used to check policy syntax and compile CIL into binary. Crucially, its -D (decompile) option can convert a binary policy back into CIL.
• secilc: The SELinux Common Intermediate Language Compiler. While used for compilation, understanding its output and structure helps in reverse engineering.
• apol: A graphical policy analysis tool from the SELinux project, offering powerful visualization and querying capabilities, though it might require local setup and compilation.
• sesearch: A command-line utility for searching specific rules within a compiled binary policy. It’s excellent for quickly finding allow, dontaudit, neverallow rules related to specific types or permissions.

Step-by-Step Policy Disassembly and CIL Conversion

Once you have extracted the binary sepolicy file, you can convert it to CIL using checkpolicy.

1. Obtaining checkpolicy

You can compile checkpolicy from the SELinux userspace tools (libselinux, checkpolicy, setools) source or find pre-compiled binaries from an Android AOSP build environment (typically located in out/host/linux-x86/bin/).

2. Decompiling the Binary Policy

Navigate to the directory containing your extracted sepolicy file and run checkpolicy with the -D flag:

checkpolicy -D -o decompiled_sepolicy.cil sepolicy

Replace sepolicy with the actual name of your binary policy file (e.g., active_sepolicy or boot_sepolicy.binary). The -o flag specifies the output CIL filename. This command will generate a comprehensive CIL file containing all the rules from the binary policy.

3. Handling Fragmented Policies (Advanced)

Modern Android versions often use a fragmented policy structure, where platform_sepolicy.cil, vendor_sepolicy.cil, and odm_sepolicy.cil are compiled together. If checkpolicy -D on the main sepolicy binary doesn’t yield the full picture or is too monolithic, you might need to analyze the individual CIL fragments before they are combined. These CIL fragments are generally easier to read directly, but represent only a part of the total policy.

Analyzing the CIL Output

With the decompiled_sepolicy.cil in hand, you can begin your analysis. The CIL file can be very large, potentially hundreds of thousands of lines. Use text processing tools like grep, awk, sed, or a powerful text editor to navigate and search.

Identifying Domains, Types, and Attributes

Look for type declarations to understand the different security contexts. attribute declarations group types with similar properties.

# Example CIL Snippet (simplified)type app_domain;attribute mlstrustedsubject;typeattribute app_domain mlstrustedsubject;type system_app_data_file, file_type, data_file_type;allow app_domain system_app_data_file:file { read write getattr };

In this snippet, app_domain is a type, and mlstrustedsubject is an attribute. The allow rule permits subjects of app_domain to read, write, and get attributes of files labeled system_app_data_file.

Searching for Specific Permissions and Rules

Use grep to search for allow, dontaudit, or neverallow rules involving specific types or classes.

• allow rules: These are the explicit permissions. Look for allow rules that grant unexpected or overly broad access. For example, grep "allow untrusted_app" might reveal permissions granted to untrusted applications.
• dontaudit rules: These suppress AVC (Access Vector Cache) messages for specific denied accesses, effectively hiding potential policy violations. They are often used to quiet expected denials, but can sometimes mask legitimate security issues. grep "dontaudit" can highlight areas where the policy might be intentionally opaque.
• neverallow rules: These are strong assertions that certain access should never be permitted. Violations indicate a serious policy error. grep "neverallow" in the CIL is a good starting point, though these are typically checked during policy compilation.

For searching the binary policy directly, sesearch is invaluable:

# Find all allow rules for 'system_app' domain to 'app_data_file' typesesearch -A -s system_app -t app_data_file sepolicy# Find all permissions related to 'ioctl' for 'zygote' processsesearch -A -s zygote -c process -p ioctl sepolicy

Identifying Vendor-Specific Modifications

Manufacturers often add their own services and features, requiring custom SELinux rules. These are usually found in vendor_sepolicy.cil or odm_sepolicy.cil. Analyzing these fragments helps understand how a vendor has extended or, potentially, weakened the standard Android policy. Look for types and rules that aren’t part of the AOSP baseline.

Advanced Analysis and Customization Implications

Once you understand the policy, you can correlate rules with system behavior. For instance, if an untrusted_app can access sensitive system properties or files, it indicates a potential vulnerability. For custom ROM developers, reverse engineering helps in creating compatible policies for new features or hardware, or in hardening existing ones. Researchers might look for policy rules that allow non-root users to execute privileged operations, which could be part of a root exploit chain.

Understanding how policies are layered and merged is also crucial. The plat_sepolicy.cil provides the base, with vendor_sepolicy.cil and odm_sepolicy.cil adding or overriding rules. This layering dictates the final enforced policy, and vulnerabilities can arise from how these layers interact.

Conclusion

Reverse engineering Android’s SELinux policy files is a foundational skill for anyone delving into Android system security. By understanding how to extract, decompile, and analyze these binary policies and their CIL counterparts, researchers gain unparalleled insights into the device’s security posture, identify manufacturer modifications, and uncover potential weaknesses. This expert-level understanding empowers more effective security hardening, vulnerability research, and custom system development within the Android ecosystem.