Introduction to SELinux on Android

Android’s security model is robust, and a cornerstone of this strength is SELinux (Security-Enhanced Linux). As a Mandatory Access Control (MAC) system, SELinux operates fundamentally differently from traditional Discretionary Access Control (DAC). While DAC allows process owners to decide access permissions, MAC enforces system-wide security policies defined by a central authority. On Android, SELinux ensures that applications and services operate within strictly defined security contexts, preventing unauthorized access to resources even if a process is compromised. This deep dive will guide you through the process of building a custom SELinux policy, transforming your understanding from a user of pre-defined policies to a security architect capable of hardening your Android device beyond default configurations.

Understanding SELinux Fundamentals

Types and Domains

At the heart of SELinux are ‘types’ and ‘domains’. A ‘type’ is a label applied to files, directories, sockets, and other objects. A ‘domain’ is a specific type assigned to a process. For instance, the ‘untrusted_app’ domain defines the permissions for most third-party applications, while ‘init’ has its own domain. SELinux policy rules then dictate which domains can access which types and in what manner (e.g., read, write, execute).

Policy Rules and Access Vector Cache (AVC) Denials

SELinux policies are essentially a set of rules that define allowed interactions. When a process attempts an action (e.g., a process in the ‘untrusted_app’ domain trying to write to a file labeled ‘system_data_file_type’), the SELinux kernel checks its policy. If no explicit ‘allow’ rule exists for that interaction, the access is denied. This denial is logged as an ‘AVC denial’ (Access Vector Cache denial) in the kernel log, providing crucial information for policy development.

Preparing Your Environment for Custom Policy Development

To build a custom SELinux policy, you’ll need an Android Open Source Project (AOSP) build environment. This typically involves syncing the AOSP source code for your target device and setting up the necessary build tools.

AOSP Build Environment

Ensure you have a complete AOSP source tree synced for your specific Android version and device. This is crucial because SELinux policies are compiled as part of the Android build system and are highly dependent on the kernel version and system architecture.

Required Tools

• adb: Android Debug Bridge for interacting with the device (shell, logcat, push/pull files).
• logcat: Essential for viewing system logs, including SELinux AVC denials.
• audit2allow: A utility (part of `policycoreutils-python` on many Linux distributions) that helps generate SELinux policy rules from AVC denials.
• An AOSP build machine: With necessary compilers and `make`/`ninja` tools.

Step-by-Step: Crafting Your First Custom Policy

Step 1: Identify the Target and Observe Initial Denials

Begin by identifying the specific application or service you want to harden or grant additional, controlled access to. Run your target application/service and observe SELinux denials using `logcat`.

adb shell logcat | grep 'avc: denied'

You’ll see output similar to this:

01-01 12:34:56.789  1234  1234 I auditd  : type=1400 audit(1672531200.000:123): avc: denied { read } for pid=789 comm="my_daemon" name="sensitive_file.txt" dev="sda" ino=123456 scontext=u:r:my_daemon:s0 tcontext=u:object_r:system_file:s0 tclass=file permissive=0

This denial tells us that `my_daemon` (source context `scontext=u:r:my_daemon:s0`) was denied `read` access to `sensitive_file.txt` (target context `tcontext=u:object_r:system_file:s0`).

Step 2: Analyze Denials and Generate Initial Rules

On your AOSP build machine, create a file (e.g., `denials.log`) and paste the relevant `avc: denied` lines into it. Then, use `audit2allow` to suggest policy rules:

audit2allow -i denials.log

Output might look like:

#============= my_daemon ==============allow my_daemon system_file:file { read getattr open };

This is a starting point, but `audit2allow` can be too broad. Always review and refine its suggestions.

Step 3: Define Your Custom Domain and Types

Navigate to the `sepolicy/private` directory in your AOSP tree. Here, you’ll define your new policy rules. Let’s create a custom type for our daemon, `my_daemon_type`.

Create a new file, e.g., `my_daemon.te`:

# my_daemon.te# Declare the domain for our custom daemontype my_daemon_type;type my_daemon_type_exec, exec_type, file_type;# Inherit necessary attributes from a base domain (e.g., 'domain')domain_auto_trans(init, my_daemon_type_exec, my_daemon_type);# Allow common operations for all domainsallow my_daemon_type { self:capability { net_admin net_raw }; }# Allow my_daemon_type to read and open files labeled as system_fileallow my_daemon_type system_file:file { read getattr open };# Allow my_daemon_type to create and manage its own runtime files (e.g., in /data/misc)type my_daemon_data_file, file_type;file_type_auto_trans(my_daemon_type, my_daemon_data_file, file);allow my_daemon_type my_daemon_data_file:dir { create search add_name write remove_name rmdir };allow my_daemon_type my_daemon_data_file:file { create read write getattr open append unlink };

If your daemon creates files or directories that need specific contexts, you’ll also need to update `file_contexts`. Find `sepolicy/private/file_contexts` and add entries:

/data/misc/my_daemon(/.*)?    u:object_r:my_daemon_data_file:s0

This ensures that any files created by `my_daemon` under `/data/misc/my_daemon` are correctly labeled `my_daemon_data_file`.

Step 4: Integrate and Compile the Policy

To integrate your new policy into the AOSP build, you typically need to add your `.te` file to the device’s `sepolicy` build configuration. This is often done by adding `my_daemon.te` to the `sepolicy/private` directory, and the Android build system will automatically pick it up if configured correctly (e.g., in `device/manufacturer/device-name/sepolicy/Android.bp` or `BoardConfig.mk`).

For example, in `BoardConfig.mk` you might see:

BOARD_SEPOLICY_DIRS += device/manufacturer/device-name/sepolicy

Ensure your `my_daemon.te` is placed in one of these included directories. Then, rebuild the `sepolicy` target:

source build/envsetup.shlunch <your_device_target>make -j$(nproc) selinux_policy

This will generate `sepolicy` files (`sepolicy`, `file_contexts`, etc.) which are usually packed into `boot.img` or `vendor_boot.img`.

Step 5: Flash and Test

After compiling, you’ll need to flash the updated `boot.img` (or `vendor_boot.img` depending on your device and Android version) to your device.

adb reboot bootloaderfastboot flash boot <path_to_boot.img>fastboot reboot

Once the device reboots, enable SELinux in `permissive` mode first to catch any remaining denials without blocking the system (optional, but highly recommended for initial testing):

adb shell su -c 'setenforce 0'

Repeat Step 1 and 2 to find any new AVC denials. Once satisfied, set SELinux to `enforcing` mode:

adb shell su -c 'setenforce 1'

Monitor `logcat` again to ensure your daemon functions correctly without new denials.

Best Practices for Robust Policies

• Principle of Least Privilege: Grant only the minimum necessary permissions. Avoid `allow domain:type * { * };` rules.
• Avoid Broad Rules: Instead of `allow my_daemon system_file:file { * };`, specify exact permissions like `{ read getattr open }`.
• Regularly Review Denials: Each denial indicates an attempted action. Understand its intent before creating a rule.
• Use Attributes: For common sets of permissions, use SELinux attributes (e.g., `storage_file_type`) to simplify policy and improve readability.
• Leverage Existing Types: Before creating new types, see if an existing Android SELinux type adequately describes the resource.

Conclusion

Building a custom SELinux policy for Android is an advanced but incredibly rewarding process. It provides granular control over system security, allowing you to harden specific components, isolate services, and significantly reduce the attack surface of your device. While the initial learning curve can be steep, the ability to define and enforce precise access controls makes you a true hero in the realm of Android system security. Remember, security is an ongoing process; continuously monitor, refine, and adapt your policies to maintain a resilient system.