Introduction to SELinux in Android Custom ROMs

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system implemented in the Android operating system to enforce granular security policies. It acts as a gatekeeper, determining which processes can access files, network sockets, and other system resources. While stock Android ROMs come with robust, thoroughly tested SELinux policies, custom Android ROMs often introduce vulnerabilities due to improper or incomplete SELinux configurations. This deep dive will equip you with the knowledge and tools to identify and mitigate such insecure configurations.

Custom ROM developers, in their pursuit of new features or broader device support, sometimes inadvertently weaken SELinux policies. This can range from setting domains to a ‘permissive’ state to introducing overly broad ‘allow’ rules, effectively bypassing the very security mechanisms SELinux is designed to provide. Understanding how to audit these configurations is paramount for anyone serious about the security and privacy of their custom Android device.

The Core Concepts of Android SELinux

Before diving into auditing, it’s crucial to grasp the fundamental concepts of SELinux on Android.

Enforcing vs. Permissive Mode

SELinux operates in two primary modes:

• Enforcing: SELinux policies are strictly enforced. Any action not explicitly allowed by the policy is denied, and a corresponding denial message (AVC denial) is logged.
• Permissive: SELinux policies are not enforced, but denial messages are still logged. This mode is often used during development to identify potential policy violations without blocking legitimate operations. However, a device running in permissive mode is significantly less secure.

You can check the current SELinux mode on your device using the following ADB command:

adb shell getenforce

If it returns “Permissive”, your device’s security posture is significantly weakened.

Contexts, Types, and Domains

SELinux uses a labeling system where every process, file, and resource has a security context. A context typically consists of user, role, type, and sensitivity (e.g., u:object_r:system_file:s0). The ‘type’ is the most critical component for policy enforcement:

• Type: Identifies the kind of object (e.g., system_file for system files, init for the init process).
• Domain: A ‘type’ specifically assigned to a process. When a process runs with a certain domain, the SELinux policy dictates what it can and cannot do.

SELinux Policy Structure

The SELinux policy is a set of rules that define allowed interactions between security contexts. These rules are usually written in a high-level language and then compiled into a binary policy file. Key components include:

• Type Definitions: Declaring types and attributes.
• Allow Rules: Explicitly permitting interactions (e.g., allow source_domain target_type:class { permissions };).
• Neverallow Rules: Defining actions that must never be permitted, acting as a strong invariant.
• File Contexts: Mapping file paths to security contexts (e.g., /system/bin(/.*)? u:object_r:system_file:s0).

Why Custom ROMs Often Get SELinux Wrong

Several factors contribute to insecure SELinux configurations in custom ROMs:

• Lack of Deep Expertise: Crafting secure SELinux policies requires a deep understanding of system processes and their interactions, which many custom ROM developers may not possess.
• Prioritizing Functionality Over Security: When encountering SELinux denials that prevent a feature from working, developers might opt for quick fixes like setting domains to permissive or adding overly broad allow rules, rather than meticulously debugging and adding precise rules.
• Copy-Pasting Policies: Reusing policies from different Android versions or device models without proper adaptation can lead to security holes or functional issues.
• Incomplete Implementation: New services or applications introduced in a custom ROM might not have properly defined SELinux contexts and rules, leading to them running with default, potentially insecure, contexts or requiring permissive mode.

Practical Steps for Auditing SELinux Policies

Preparing Your Environment

To effectively audit SELinux policies, you’ll need:

• ADB (Android Debug Bridge): For interacting with your device.
• AOSP Source Code (Optional but Recommended): This provides access to crucial SELinux tools like sepolicy-analyze and apol, which are invaluable for detailed analysis. You can typically find pre-compiled versions or build them from the AOSP source.
• A Linux environment: For running the analysis tools.

Extracting the Policy

You can extract the SELinux policy from a running device or from its boot.img/vendor_boot.img.

From a running device:

adb shell su -c 'cat /sys/fs/selinux/policy' > policy.raw

From boot.img (more reliable for the full policy):

1. Extract boot.img from your device’s firmware or a custom ROM zip.
2. Use a tool like magiskboot (part of Magisk, can be run on PC) or Android Image Kitchen to unpack the boot.img. The SELinux policy is usually found within the ramdisk, often as sepolicy or similar.
3. Locate and copy the sepolicy file (this is your policy.raw).

Analyzing the Policy with AOSP Tools

Once you have policy.raw, you can use AOSP’s SELinux analysis tools:

1. `apol` (Android Policy Analysis Tool): This powerful tool can detect policy issues, potential vulnerabilities, and deviations from AOSP’s `neverallow` rules.

First, ensure you have the necessary policy files (e.g., `platform_sepolicy`, `vendor_sepolicy`) from your AOSP build, as `apol` often needs to compare against the source policy.

# Example usage (adjust paths to your AOSP source)apol -p policy.raw -a /path/to/aosp/build/target/product/sepolicy-policy-src/ -o audit_report.txt

Review `audit_report.txt` for `neverallow` violations, policy warnings, and potential vulnerabilities.

2. `sepolicy-analyze`: Useful for querying specific information about the policy.

To list all domains that are in permissive mode:

sepolicy-analyze policy.raw permissive

To list all file contexts:

sepolicy-analyze policy.raw file_contexts

Monitoring SELinux Denials

Even with a static policy analysis, real-time monitoring of denials is crucial for dynamic issues.

adb shell dmesg | grep 'avc: 'adb shell logcat | grep 'selinux'

Repeated or unexpected AVC denials can indicate an improperly configured SELinux policy, especially if they occur during normal device operation.

Identifying Common Insecure Patterns

Permissive Domains

The most straightforward sign of a weakened policy is a domain being set to permissive. While sometimes necessary for new services in early development, a production ROM should have very few, if any, permissive domains.

Look for lines like these in the policy source (if available) or output from `sepolicy-analyze`:

permissive some_new_service_domain;

Any domain set to permissive essentially allows processes running in that domain to bypass SELinux restrictions, creating a significant attack surface.

Overly Broad `allow` Rules

These are more subtle but equally dangerous. An overly broad rule grants more permissions than necessary, potentially allowing an exploited process to escalate privileges.

Examples to look for:

• Wildcard permissions: allow some_domain other_type:class { * }; (grants all permissions for that class)
• Generic file permissions: allow app_domain system_file:file { execute }; where app_domain should not need to execute arbitrary system files.
• Inter-domain communication: allow untrusted_app system_server:binder { call transfer }; if untrusted_app should only be able to call specific services.

Use `apol` or manual inspection to find rules granting excessive privileges. Pay close attention to rules involving highly privileged domains (e.g., `init`, `system_server`, `priv_app`) or user-facing applications interacting with system resources.

Incorrect File Contexts

Files and directories must have appropriate SELinux contexts. If a sensitive file has an incorrect or default context (e.g., `unlabeled`), it might be accessible to domains that should not have access. This is often seen with new files added by custom ROMs.

You can check file contexts on the device:

adb shell ls -Z /data/local/tmp/some_new_binaryadb shell ls -Z /system/bin/some_custom_tool

Compare these to expected contexts defined in `file_contexts` (often found in `/sepolicy/file_contexts` in the policy source or generated from `sepolicy-analyze`). For example, a system binary should ideally be labeled `u:object_r:system_file:s0`.

`neverallow` Violations

Android’s `neverallow` rules are critical for maintaining the integrity of the security model. They specify actions that must *never* be allowed, even if an `allow` rule permits it. Violations indicate that the policy has been deliberately or accidentally weakened in a way that Google explicitly deemed insecure.

`apol` is excellent at detecting these violations. A custom ROM with `neverallow` violations is fundamentally insecure and should be approached with extreme caution.

Remediation and Hardening Best Practices

Once insecure configurations are identified, they must be addressed:

• Principle of Least Privilege: Grant only the minimal permissions necessary for a process or application to function.
• Specific Rules: Avoid broad wildcard rules. Instead of allow app_domain self:capability { * };, use allow app_domain self:capability { net_raw net_admin }; for specific network capabilities.
• Proper File Labeling: Ensure all new files and directories introduced by the custom ROM have appropriate and secure SELinux contexts defined in `file_contexts`.
• Eliminate Permissive Domains: Gradually transition permissive domains to enforcing by addressing all AVC denials with precise `allow` rules.
• Validate Against `neverallow` Rules: Ensure the custom policy does not violate any `neverallow` rules from the AOSP base, indicating a strong commitment to core Android security.

Conclusion

SELinux is a cornerstone of Android’s security architecture. While custom Android ROMs offer unparalleled flexibility and features, they often come with the hidden risk of insecure SELinux configurations. By understanding the core concepts and employing systematic auditing techniques, you can unmask these vulnerabilities. A vigilant approach to SELinux policy analysis and hardening is not just an advanced technical skill; it’s a critical practice for safeguarding your device and personal data in the custom Android ecosystem.