The Imperative for Custom SELinux Policies in Android

In the evolving landscape of Android security, SELinux (Security-Enhanced Linux) stands as a critical mandatory access control (MAC) mechanism, providing granular control over system resources. While Android ships with a robust default SELinux policy, it’s designed for generic devices and core system components. When integrating custom services, daemons, or applications, especially in specialized Android builds for enterprise, IoT, or embedded systems, relying solely on the default policy often leads to either over-permissiveness (security risk) or under-permissiveness (functionality breakage). Building your own SELinux policy allows you to enforce the principle of least privilege, ensuring your custom components only access the resources strictly necessary for their operation, thereby significantly enhancing device security and integrity.

SELinux Fundamentals on Android

Core Concepts: Types, Domains, and Rules

At its heart, SELinux operates on labels. Every file, process, socket, and IPC mechanism on an SELinux-enabled system is assigned a security context, which includes its type. Processes run within specific domains (a type specifically for processes), and access is granted or denied based on rules that define how domains can interact with types. Key concepts include:

• Type: The primary identifier for a security context (e.g., system_server_t, system_file_t).
• Domain: A specific type assigned to a process, defining its allowed actions.
• Class: Categorizes resources (e.g., file, socket, binder, capability).
• Permission: The specific action allowed within a class (e.g., read, write, execute, call).

Policy rules are typically expressed as allow source_domain target_type:class permission_set;

Policy Structure and Layers

Android’s SELinux policy is composed of multiple layers: the AOSP base policy (`system/sepolicy`), vendor policies, and device-specific policies. During the build process, these `.te` (type enforcement) files are compiled into a single binary policy (`sepolicy`) that resides in the boot image.

Setting Up Your Development Environment

To build custom SELinux policies, you’ll need an Android Open Source Project (AOSP) build environment. This provides the necessary compilers, tools (`checkpolicy`, `audit2allow`), and the base policy files. We assume you have a working AOSP environment synced and ready.

# Initialize the AOSP build environment (replace with your build target)source build/envsetup.shlunch aosp_arm64-userdebug# Navigate to a convenient working directory for your custom policymkdir -p vendor/mycompany/sepolicycd vendor/mycompany/sepolicy

Identifying and Defining Your Custom Component’s Needs

Before writing policy, thoroughly analyze your custom service or app:

• What is its purpose?
• What files does it read/write? Where are they located?
• Does it communicate with other processes via Binder, sockets, or IPC?
• Does it require specific kernel capabilities (e.g., `CAP_NET_ADMIN`, `CAP_SYS_RAWIO`)?
• What directories does it create or access?

For this tutorial, let’s imagine a custom service named `myservice` that runs as a daemon, needs to read a configuration file from `/data/vendor/myservice/config.txt`, write logs to `/data/vendor/myservice/logs/`, and communicate over a Unix domain socket with a client application.

Crafting Your Custom SELinux Policy

All custom policy definitions should reside in a `.te` file, for example, `myservice.te`.

Creating a New Domain Type

First, define the process domain for `myservice` and its executable type:

# vendor/mycompany/sepolicy/myservice.te# Define the type for our myservice process. It's a domain.type myservice_service, domain;# Define the type for the myservice executable. It's an executable file,system_file_type means it's part of the system image.type myservice_exec, exec_type, file_type, system_file_type;

Initializing the Domain

If your service is started by `init` (common for daemons), you’ll need rules to transition `init` into your service’s domain:

# Allow init to execute our myservice and transition to its domaininit_daemon_domain(myservice_service)

Defining Access Rules

Now, define what `myservice_service` can do. Start with what it needs:

# Allow myservice to manage its own process (e.g., set capabilities)allow myservice_service self:process { capability setcap setsched signal };# Allow myservice to execute its own binaryallow myservice_service myservice_exec:file { execute_no_trans entrypoint };# Allow reading from /dev/null, /dev/urandom (common for many services)allow myservice_service dev_null:chr_file { read write };allow myservice_service urandom_device:chr_file { read };# Define a new type for myservice's data directory and files# We'll put these in a separate file, e.g., myservice_data.te# For now, let's assume myservice_data_file and myservice_data_dir are defined.# Allow myservice to create, read, write its config/log filesallow myservice_service myservice_data_file:file { create read write open getattr setattr unlink };allow myservice_service myservice_data_dir:dir { add_name remove_name read write search rmdir setattr create };# Allow socket communication (example for a Unix domain socket)type myservice_socket, file_type, data_file_type;# In another file (e.g., myservice_socket.te), define:unix_socket_send(myservice_service, myservice_socket)unix_socket_connect(myservice_service, myservice_socket)# And for the server side:allow myservice_service myservice_socket:sock_file { create unlink setattr };allow myservice_service self:unix_stream_socket { accept bind listen connect read write getattr setopt };

For the data files, create `myservice_data.te`:

# vendor/mycompany/sepolicy/myservice_data.tetype myservice_data_file, data_file_type;type myservice_data_dir, data_file_type;# Allow myservice_service to use its data directory and filesallow myservice_service myservice_data_dir:dir { create search rmdir add_name remove_name write };allow myservice_service myservice_data_file:file { read write create open getattr setattr unlink };# This allows files created within myservice_data_dir to inherit its typefile_type_auto_trans(myservice_service, myservice_data_dir, myservice_data_file);

Labeling Files and Directories

You need to tell SELinux what context to assign to your service’s executable and its data directory. This is done in a `file_contexts` file.

# vendor/mycompany/sepolicy/file_contexts/myservice_file_contexts/data/vendor/myservice(/.*)? u:object_r:myservice_data_dir:s0/vendor/bin/myservice u:object_r:myservice_exec:s0

Compiling and Integrating the Policy

1. Place your `.te` and `file_contexts` files in a new directory, e.g., `vendor/mycompany/sepolicy`. Your structure might look like this:

vendor/mycompany/sepolicy/├── Android.bp├── myservice.te├── myservice_data.te├── file_contexts/│   └── myservice_file_contexts

2. Add an `Android.bp` file in `vendor/mycompany/sepolicy` to build your policy:

# vendor/mycompany/sepolicy/Android.bpsepolicy_split_add(  name: "mycompany_sepolicy_split",  domain_files: [    "myservice.te",    "myservice_data.te",  ],  neverallow_files: [    # Add any specific neverallow rules here  ],  file_contexts: [    "file_contexts/myservice_file_contexts",  ],  # Set target_init_daemon_files if your service is started by init.  target_init_daemon_files: [    "myservice.te",  ],)

3. In your device’s `BoardConfig.mk` (e.g., `device/google/marlin/BoardConfig.mk`), include your custom policy directory:

# device/google/marlin/BoardConfig.mk (or your device's equivalent)BOARD_SEPOLICY_DIRS += vendor/mycompany/sepolicy

4. Rebuild your Android image. This will compile your SELinux policy and integrate it into the boot image:

m -j$(nproc) bootimage

Or, if you only changed policy files and want a quicker build:

make sepolicy

Flash the new boot image to your device.

Debugging and Refinement

Identifying Denials

After flashing, if your service misbehaves or doesn’t start, SELinux is likely blocking it. Look for Access Vector Cache (AVC) denials in the kernel logs:

adb shell dmesg | grep avcadb shell logcat | grep selinux

An AVC denial typically looks like: `avc: denied { permission } for pid=XXX comm=”process_name” scontext=u:r:source_domain:s0 tcontext=u:object_r:target_type:s0 tclass=class_name`

Using audit2allow

The `audit2allow` tool can generate policy rules from AVC denials. Copy denial messages into a file (e.g., `audit.log`) and run:

cat audit.log | audit2allow -M myservice_temp_policy

This generates `myservice_temp_policy.te` and `myservice_temp_policy.cil`. Review the `.te` file carefully. `audit2allow` can be overly permissive, so add only the necessary rules to your `myservice.te` file.

Policy Enforcement Modes

During development, you can temporarily set SELinux to permissive mode to allow all actions while still logging denials. This helps identify all required permissions without blocking functionality:

adb shell setenforce 0 # Set to permissive modeadb shell setenforce 1 # Set back to enforcing mode

Remember to always run in `enforcing` mode for production builds.

Best Practices and Advanced Considerations

• Principle of Least Privilege: Grant only the absolute minimum permissions required.
• Avoid `dontaudit`: Do not use `dontaudit` rules during initial development, as they suppress denials, making debugging difficult. Use them sparingly in production only for known, benign, high-volume denials.
• `neverallow` Rules: These rules explicitly forbid certain interactions, serving as a powerful sanity check against accidental over-privilege. Leverage them for critical security boundaries.
• Modular Policy: Keep your policy files organized and modular, separating concerns into different `.te` files.
• Context Persistence: Ensure that any files or directories created by your custom service inherit the correct SELinux context. This is crucial for their security and accessibility.

By carefully crafting and rigorously testing your SELinux policies, you can significantly enhance the security posture of your custom Android components, moving beyond default protections to a truly fine-grained control system.