Introduction to SELinux on Android

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system that provides a mechanism for supporting access control security policies. Integrated deeply into Android since version 4.3 Jelly Bean, SELinux is a critical component for enhancing the platform’s security posture. Unlike discretionary access control (DAC) systems, where users can control access to their own files, MAC systems enforce a system-wide security policy that cannot be overridden by users. For Android, this means even a root user or a compromised application cannot arbitrarily access system resources without explicit permission defined in the SELinux policy.

While Android ships with a default SELinux policy, many custom ROMs or modified devices might run in a ‘permissive’ state, which logs policy violations but does not prevent them. Transitioning from permissive to a ‘fully enforcing’ SELinux mode is paramount for true device hardening, significantly reducing the attack surface and mitigating the impact of potential vulnerabilities.

Understanding SELinux Modes: Permissive vs. Enforcing

SELinux operates primarily in two modes:

• Permissive Mode: In this mode, SELinux policy violations are logged to the kernel’s audit log (`dmesg` or `logcat`) but are not blocked. This mode is invaluable during policy development and debugging, as it allows developers to identify what would be blocked without actually breaking the system.
• Enforcing Mode: This is the desired state for a secure system. In enforcing mode, SELinux policy violations are not only logged but are also actively blocked, preventing unauthorized operations.

You can check the current SELinux mode on your Android device using adb shell getenforce:

$ adb shell getenforce
Enforcing

To temporarily switch modes (requires root), you can use setenforce 0 for permissive and setenforce 1 for enforcing. Keep in mind that these changes are not persistent across reboots.

$ adb shell su -c "setenforce 0"
$ adb shell getenforce
Permissive
$ adb shell su -c "setenforce 1"
$ adb shell getenforce
Enforcing

Setting Up Your Policy Development Environment

Developing and refining SELinux policies for Android typically requires access to the Android Open Source Project (AOSP) source code. This provides the necessary tools and the original policy files to modify.

• AOSP Source Tree: Download and build the AOSP for your target device. This will give you the complete system/sepolicy directory, along with the build system to compile new policies.
• ADB (Android Debug Bridge): Essential for interacting with your device, pulling logs, and pushing new policy files.
• sepolicy-analyze: A powerful tool within the AOSP build environment (typically found in out/host/linux-x86/bin/ after a build) for analyzing existing policies, understanding type transitions, and identifying potential issues.

Identifying SELinux Denials

The first and most critical step in hardening your device’s SELinux policy is to identify all existing denials that occur when your device is running in permissive mode. These denials tell you exactly what actions are being blocked (or would be blocked in enforcing mode) and for what reason.

Denials are logged in the kernel’s audit messages. You can retrieve them using dmesg or logcat:

$ adb shell dmesg | grep avc
$ adb logcat | grep selinux

An example AVC (Access Vector Cache) denial message looks like this:

audit: avc: denied { write } for pid=1234 comm="my_service" name="some_file" dev="dm-0" ino=12345 scontext=u:r:my_service_domain:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=1

Let’s break down this example:

• denied { write }: The specific permission that was denied.
• pid=1234 comm="my_service": The process ID and name of the executable attempting the action.
• name="some_file": The name of the target resource.
• scontext=u:r:my_service_domain:s0: The source context, identifying the domain of the process.
• tcontext=u:object_r:app_data_file:s0: The target context, identifying the type of the resource.
• tclass=file: The class of the target resource (e.g., file, directory, socket).
• permissive=1: Indicates the device was in permissive mode. If it were enforcing, this would likely be enforcing=1.

Developing and Modifying SELinux Policy

Armed with denial logs, you can begin to develop or modify your SELinux policy. Android’s SELinux policy is primarily defined in .te (type enforcement) files, along with file_contexts, seapp_contexts, and mac_permissions.xml.

Key Policy Files:

• .te files (e.g., system/sepolicy/public/untrusted_app.te): Define types, attributes, domains, and the rules (allow, neverallow) governing interactions between them.
• file_contexts (e.g., system/sepolicy/private/file_contexts): Maps filesystem paths to SELinux types. This tells SELinux how to label files and directories.
• seapp_contexts (e.g., system/sepolicy/private/seapp_contexts): Maps Android application packages/UIDs to SELinux domains.

The Policy Modification Workflow:

1. Replicate the Denial: Ensure you can consistently trigger the denial in permissive mode.
2. Analyze the Denial: Understand the `scontext`, `tcontext`, `tclass`, and `permission`.
3. Locate/Create Relevant .te File: For custom services or applications, you might need to create a new domain (e.g., my_service.te) or modify an existing one (e.g., device/<vendor>/<device>/sepolicy/<policy_name>.te).
4. Add an allow Rule: Based on the denial, add the minimum necessary permission. For the example denial above, if my_service_domain legitimately needs to write to a file labeled app_data_file, you might add:

   allow my_service_domain app_data_file:file write;

   However, it’s generally better to define more specific types if possible. For instance, if `my_service` needs to write to its own data directory:

   # In my_service.te
   type my_service_data_file, file_type, data_file_type;
   
   allow my_service_domain my_service_data_file:file { create_file_perms };
   allow my_service_domain my_service_data_file:dir { create_dir_perms };

5. Update file_contexts: If you created a new type for files/directories, you must label them in file_contexts:

   /data/media/0/my_service_data(/.*)? u:object_r:my_service_data_file:s0

6. Build and Flash Policy: Recompile your AOSP source. The SELinux policy is typically compiled into sepolicy (or sepolicy.cil) which is part of the boot image. Flash the new boot image to your device:

   $ cd /path/to/aosp/out/target/product/<device>
   $ adb reboot bootloader
   $ fastboot flash boot boot.img

7. Test and Iterate: Reboot the device, re-check the SELinux mode (it should be enforcing), and test the functionality that previously generated denials. If new denials appear, repeat the process. This is an iterative process that requires patience.

Transitioning to Full Enforcing Mode

Once you have resolved all critical denials and your system runs stably in permissive mode (meaning you’ve addressed all the `avc: denied` messages for expected functionality), you’re ready to make the switch to full enforcing mode persistently.

This is typically done by modifying the kernel command line arguments. In your device’s BoardConfig.mk file (or similar configuration for your device tree), you’ll find a variable like BOARD_KERNEL_CMDLINE. Ensure it includes androidboot.selinux=enforcing.

# Example from device/manufacturer/device_name/BoardConfig.mk
BOARD_KERNEL_CMDLINE += androidboot.selinux=enforcing

After making this change, rebuild your boot image and flash it. Upon reboot, your device should consistently start in enforcing mode. At this point, closely monitor dmesg and logcat for any new denials. It’s common for subtle interactions to surface only in full enforcing mode.

Best Practices and Common Pitfalls

• Principle of Least Privilege: Always grant the minimum necessary permissions. Broad allow rules (e.g., `allow domain type:class *;`) are security holes.
• Granular Types: Define specific types for specific resources. Avoid reusing general types for custom components.
• Use Attributes: Leverage attributes to group types with similar characteristics, making policy maintenance easier and more readable.
• Neverallow Rules: Pay attention to existing neverallow rules in the AOSP policy. These are critical security constraints that should generally not be violated. If you encounter a conflict, re-evaluate your design.
• Iterative Development: SELinux policy development is rarely a one-shot process. Start in permissive, resolve denials, switch to enforcing, resolve new denials, and repeat.
• Version Control: Keep all your policy modifications under version control. This allows you to track changes, revert mistakes, and merge updates from upstream AOSP.
• Thorough Testing: After every policy change, rigorously test all affected functionalities. Don’t assume an `allow` rule will fix everything without introducing new issues.

Mastering SELinux policy development is a significant step towards hardening Android devices. It requires a deep understanding of system interactions and a methodical approach to policy refinement, but the security benefits are well worth the effort.