Introduction: The Limitations of audit2allow

Android’s security model heavily relies on SELinux, a mandatory access control (MAC) system that enforces granular permissions across the operating system. When developing custom ROMs, modifying system services, or integrating new hardware, you’ll inevitably encounter SELinux AVC (Access Vector Cache) denials. The common first response is often to use the audit2allow tool, which automatically generates SELinux policy rules based on denial logs. While convenient for quick fixes, audit2allow frequently produces overly broad or incorrect rules, leading to a less secure system or masked issues.

This article dives into advanced techniques for understanding, writing, and debugging Android SELinux policies, moving beyond the blunt instrument of audit2allow to craft precise, secure, and maintainable rules. We’ll explore how to interpret AVC denials, inspect existing policies, write custom .te (type enforcement) files, and employ sophisticated debugging strategies.

Understanding AVC Denials: The Core of Debugging

Every SELinux denial provides crucial information about why an operation was blocked. These denials are logged in the kernel message buffer (dmesg) and are the starting point for any policy refinement. A typical AVC denial looks like this:

adb shell dmesg | grep avc

avc: denied { read } for pid=1234 comm="my_service" name="some_file" dev="dm-0" ino=5678 scontext=u:r:my_service:s0 tcontext=u:object_r:system_file:s0 tclass=file permissive=0

Let’s break down the key fields:

• denied { read }: The permission that was denied (e.g., read, write, execute, getattr).
• pid=1234 comm="my_service": The process ID and name of the executable attempting the action. This identifies the subject of the denial.
• name="some_file": The name of the target file or object.
• scontext=u:r:my_service:s0: The security context of the subject (the process trying to access something). Here, my_service is the domain type.
• tcontext=u:object_r:system_file:s0: The security context of the target (the resource being accessed). Here, system_file is the type of the target.
• tclass=file: The class of the target object (e.g., file, dir, socket, service).
• permissive=0: Indicates SELinux is in enforcing mode. If permissive=1, it would be logging denials but not blocking actions.

By carefully analyzing these fields, you can pinpoint exactly which subject type tried to perform which action on which target type and class. This precision is vital for writing targeted policy rules.

Inspecting Existing Policies with sepolicy-analyze

Before writing new rules, it’s essential to understand the existing policy. The sepolicy-analyze tool, available in the Android build environment, is invaluable for this. You’ll typically find the compiled policy at out/target/product/<device>/root/sepolicy.

# On your host machine, after building Android
cd <ANDROID_BUILD_ROOT>
.
build/envsetup.sh
# Find the compiled sepolicy file (may vary slightly by device/version)
policy_file=$(find out -name sepolicy -print -quit)

# List all defined types
sepolicy-analyze ${policy_file} type

# List all attributes
sepolicy-analyze ${policy_file} attribute

# Find all rules allowing 'read' access to 'system_file' by 'my_service' domain
sepolicy-analyze ${policy_file} allow my_service system_file file read

# Find all dontaudit rules
sepolicy-analyze ${policy_file} dontaudit

This tool helps you discover existing types, attributes, and their relationships, guiding you to reuse existing policy components rather than creating redundant or conflicting ones.

Crafting Custom .te Files: Precision Policy Writing

Android SELinux policy is written in individual .te files (type enforcement) which are then compiled into a single sepolicy binary. When adding a new service or modifying an existing one, you’ll create or modify these files, typically located under device/<vendor>/<device>/sepolicy or a project-specific directory.

Defining a New Service Domain

Let’s say you’re adding a new native service named my_custom_service that needs to run as a separate SELinux domain.

# In device/<vendor>/<device>/sepolicy/my_custom_service.te

type my_custom_service, domain;
type my_custom_service_exec, exec_type, file_type, system_file_type;

# Assign to init's domain transition for services started by init
init_daemon_domain(my_custom_service)

# Allow the service to read/write its own data directory
allow my_custom_service my_custom_service_data_file:file { create_file_perms r_file_perms w_file_perms };
allow my_custom_service my_custom_service_data_file:dir { create_dir_perms r_dir_perms w_dir_perms };

# Where 'my_custom_service_data_file' is defined in file_contexts
# e.g., /data/misc/my_service(/.*)?  u:object_r:my_custom_service_data_file:s0

# Allow logging and basic network access (if needed)
allow my_custom_service logd:binder call;
allow my_custom_service self:socket create_socket_perms;
allow my_custom_service node:tcp_socket name_connect;
allow my_custom_service domain:fd use;

In this example:

• We define my_custom_service as a new domain.
• my_custom_service_exec is for the executable itself.
• init_daemon_domain(my_custom_service) is a macro that grants common permissions for services started by init, including domain transition from init.
• Specific allow rules grant access to its own data, basic logging, and network capabilities.

Using dontaudit and neverallow

• dontaudit: This directive tells SELinux to suppress logging of specific denials. Use with extreme caution! It’s primarily for suppressing expected, non-critical denials that cannot be easily fixed or are considered benign noise. Overuse of dontaudit can hide legitimate security issues.

  # Example: Suppress a specific denial you've deemed harmless
  dontaudit my_domain other_domain:file read;

• neverallow: Crucial for security hardening. neverallow rules specify permissions that are *never* allowed, even if explicit allow rules grant them. These rules are compile-time checks that enforce security invariants across the entire policy. If an allow rule violates a neverallow, the policy compilation will fail, forcing developers to fix the underlying issue.

  # Example: Prevent any domain from writing to kernel modules
  neverallow { domain } kernel_module:file { write append link unlink rename setattr };
  
  # Prevent apps from directly writing to system properties
  neverallow { appdomain } property_data_file:file { write create_file_perms };

  neverallow rules significantly enhance the security posture of an Android device by preventing accidental or malicious policy regressions.

Conditional Policies

Sometimes, policy rules need to be conditional, for instance, only enabled in debug builds. This can be achieved using ifdef statements.

# In a .te file

# Only allow debug features if TARGET_BUILD_VARIANT is userdebug or eng
ifdef(`target_debug_build', `
  allow my_service debugfs:file { read write open };
')

The target_debug_build macro is defined in the Android build system and resolves to true for userdebug and eng builds.

Advanced Debugging Strategies

Temporarily Permissive Mode

For complex debugging scenarios, setting SELinux to permissive mode temporarily can help. This logs all denials without enforcing them, allowing you to identify a cascade of issues quickly.

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

Warning: Never ship a device with SELinux in permissive mode. It compromises the entire security model.

Targeted auditd Logging (if available)

On some Android versions or custom setups, auditd might be running. If so, you can use auditctl to add specific rules to focus your logging efforts.

# On device (requires root and auditd service)
auditctl -a always,exit -F arch=b32 -S execve -F auid!=4294967295 -k execs_by_unconfined

This allows for more granular control over what gets logged compared to just grepping dmesg.

Tracing Policy Resolution

When an AVC denial occurs, it’s not always clear which specific policy rule or lack thereof caused it. Tracing how SELinux resolves permissions can be complex, involving type transitions, roles, and conditional policies. A deep dive often requires examining the compiled sepolicy with tools like sesearch (from the SELinux userspace tools, potentially cross-compiled for Android) or manually inspecting the source .te files for all interactions between the subject and target types.

Conclusion

Mastering Android SELinux policy involves moving beyond reactive audit2allow usage. By deeply understanding AVC denials, leveraging inspection tools like sepolicy-analyze, and carefully crafting precise .te files with a focus on neverallow rules, developers can build more secure and robust Android systems. This iterative process of analyzing, refining, and debugging is fundamental to maintaining a strong security posture in advanced Android customizations.