Introduction: Navigating Android’s SELinux Labyrinth
Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system that forms the bedrock of Android’s security model. It defines granular permissions for every process, file, and resource on the system, preventing unauthorized access and privilege escalation. While AOSP (Android Open Source Project) implements a robust SELinux policy, custom ROMs, especially those derived from AOSP or heavily modified, often struggle with maintaining a fully functional and secure `enforcing` policy. This can lead to ROMs defaulting to `permissive` mode (where denials are logged but not enforced), leaving devices vulnerable, or conversely, having overly restrictive policies that break legitimate functionality.
This expert-level guide will demystify SELinux policy on Android. We’ll explore how to reverse engineer existing policies, identify security violations, and ultimately modify or inject custom rules to achieve a balance between security and functionality in your custom ROM environment. This lab will equip advanced users and ROM developers with the tools and knowledge to take control of their device’s security.
Understanding SELinux Fundamentals on Android
At its core, SELinux operates on labels. Every file, process, and system resource is assigned a security context (e.g., `u:object_r:system_file:s0`). Policy rules then dictate what actions one context (a source, typically a process domain) can perform on another context (a target, e.g., a file type). Key concepts include:
- Contexts: A label applied to every object and subject, consisting of user, role, type, and sensitivity.
- Types/Domains: The most critical part of the context for policy decisions. A process’s type is its domain.
- Rules: Expressed as `allow source_type target_type:class operation;` (e.g., `allow untrusted_app system_file:file { read execute getattr };`).
- `sepolicy` files: A collection of `.te` (type enforcement) files that define the policy, compiled into a binary `sepolicy` file.
The distinction between `enforcing` and `permissive` modes is crucial. In `enforcing` mode, any action not explicitly permitted by the policy is denied. In `permissive` mode, such actions are allowed, but a denial message (an AVC denial) is logged in the kernel’s audit log. While permissive mode can be useful for debugging, it severely compromises security.
Checking Current SELinux Status
You can quickly check your device’s SELinux status via ADB:
adb shell getenforce
This will return either `Enforcing` or `Permissive`. To temporarily switch to permissive (for debugging purposes, not recommended for daily use):
adb shell su 0 setenforce 0
And back to enforcing:
adb shell su 0 setenforce 1
Setting Up Your SELinux Policy Lab
To effectively reverse engineer and modify SELinux policies, you’ll need a robust toolkit:
- Rooted Android Device: Essential for `adb shell su` access and pushing/pulling sensitive files.
- ADB (Android Debug Bridge): For device communication.
- `audit2allow`: A tool to generate SELinux policy rules from audit logs.
- `sepolicy-inject`: A utility to directly modify the binary `sepolicy` file on device without full recompilation. (Alternatively, a full AOSP build environment for `sepolicy` compilation).
- `sesearch` (optional): For querying compiled SELinux policies.
Extracting Device Policy Files
First, pull the current `sepolicy` and related context files from your device:
adb pull /sys/fs/selinux/policy sepolicy.imgadb pull /file_contexts file_contexts.adb pull /seapp_contexts seapp_contexts.adb pull /property_contexts property_contexts.adb pull /service_contexts service_contexts.
The `sepolicy.img` is the compiled binary policy. The `*_contexts` files map specific files, apps, properties, and services to their respective SELinux types.
Identifying Policy Violations with Audit Logs
The most common scenario for policy modification arises when an application or service fails to function in `enforcing` mode. The key to fixing this lies in the kernel’s audit logs.
Capturing AVC Denials
Switch your device to `permissive` mode (if not already) and try to reproduce the failing functionality. Then, capture the audit logs:
adb shell dmesg | grep 'avc: ' > avc_denials.txtadb shell logcat -b all | grep 'avc: ' >> avc_denials.txt
Examine `avc_denials.txt`. You’ll see entries like:
avc: denied { read } for pid=1234 comm="my_daemon" name="device_node" dev="tmpfs" ino=5678 scontext=u:r:my_daemon_domain:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
This log indicates `my_daemon` (source context `my_daemon_domain`) was denied `read` access to `device_node` (target context `device`, class `chr_file`).
Generating Rules with `audit2allow`
Feed these audit logs into `audit2allow` to generate initial policy rules. For example, if your audit log contains the above denial:
audit2allow -i avc_denials.txt
This might output:
#============= my_daemon_domain ==============allow my_daemon_domain device:chr_file read;
This is a potential policy rule. Review it carefully, as `audit2allow` can sometimes be overly broad. Always aim for the principle of least privilege.
Reverse Engineering Existing `sepolicy`
Before adding new rules, it’s beneficial to understand the existing policy. Tools like `sesearch` can query the compiled `sepolicy` image.
Using `sesearch` to Query Policy
First, you might need to convert `sepolicy.img` to a human-readable format, often a Common Intermediate Language (`.cil`) file. If you have the AOSP `sepolicy` tools, you can use `apol –output /path/to/policy.cil sepolicy.img`.
Then, `sesearch` (part of the `libsepol` and `libselinux` development packages) can be used. For example, to find all permissions granted to `my_daemon_domain`:
sesearch -A -s my_daemon_domain -p sepolicy.img
Or to find what can write to `device` type:
sesearch -A -t device -c file -P write -p sepolicy.img
This helps you understand existing rules and prevent redundant or conflicting additions. You might find that a similar process already has the needed permission, or that your domain needs to inherit from a more privileged type.
Modifying and Injecting Policy Rules
There are two primary ways to modify SELinux policy: recompiling from source (complex, requires full AOSP environment) or injecting rules into the binary `sepolicy` using tools like `sepolicy-inject`.
Using `sepolicy-inject` for Quick Modifications
`sepolicy-inject` is an invaluable tool for on-the-fly policy adjustments, especially in custom ROM scenarios where rebuilding the entire `sepolicy` from source is impractical for minor fixes. Let’s assume you’ve identified a needed rule:
allow my_daemon_domain custom_device_file:chr_file { read write open };
You would create a `.cil` file (e.g., `my_custom_rules.cil`) with your new rules:
(allow my_daemon_domain custom_device_file (chr_file (read write open)))
Then, use `sepolicy-inject` to inject this into your `sepolicy.img`:
sepolicy-inject -s my_daemon_domain -t custom_device_file -c chr_file -p read,write,open -P sepolicy.img -o sepolicy_modified.img
For more complex additions (like new types or attributes), you might need to use the `-f` flag with a `.cil` fragment:
sepolicy-inject -i sepolicy.img -o sepolicy_modified.img --file my_custom_rules.cil
This method allows you to add specific `allow` rules, `type` declarations, `attribute` assignments, and more directly.
Updating Context Files (If Necessary)
If your new rule involves a file or service that doesn’t have an appropriate context yet, you’ll need to update `file_contexts` or `service_contexts`. For instance, if `custom_device_file` previously had a generic `device` context, but you created a more specific `custom_device_file` type, you’d add an entry:
/dev/my_custom_device u:object_r:custom_device_file:s0
Then push this updated `file_contexts` back to your device.
Deployment and Verification
Once you have your `sepolicy_modified.img` and potentially updated context files, it’s time to deploy and test.
- Push Modified `sepolicy`:
adb push sepolicy_modified.img /data/local/tmp/sepolicy
- Load Policy (requires root):
adb shell su 0 load_policy /data/local/tmp/sepolicy
Note: Some devices or ROMs might restrict `load_policy` or require a reboot to fully apply changes if the policy is loaded early in the boot process. In such cases, you might need to replace `/vendor/etc/selinux/sepolicy` or `/sepolicy` directly (requiring `remount` and careful handling).
- Verify Enforcing Mode:
adb shell getenforce
Ensure it reports `Enforcing`.
- Test Functionality: Try to reproduce the issue that previously caused AVC denials. If it now works, and no new denials appear, your policy modification was successful. If new denials appear, repeat the `audit2allow` process.
Conclusion: Mastering Your Android’s Security Posture
Managing SELinux policy on custom Android ROMs is a critical skill for advanced users and developers. By understanding the fundamentals, leveraging audit logs, and utilizing powerful tools like `audit2allow` and `sepolicy-inject`, you can transform a `permissive` or buggy `enforcing` environment into a secure and functional one. This hands-on approach not only enhances your device’s security but also deepens your understanding of Android’s internal workings. Remember to always prioritize the principle of least privilege, granting only the necessary permissions to maintain a strong security posture.