Introduction to SELinux on Android IoT

Security-Enhanced Linux (SELinux) is a mandatory access control (MAC) system implemented at the kernel level, pivotal for securing Android-based Internet of Things (IoT) devices, automotive systems, and smart TVs. Unlike discretionary access control (DAC), which allows the owner of a resource to define its permissions, SELinux enforces a policy defined by the system administrator, providing fine-grained control over what processes can access which resources. For embedded Android systems, where security vulnerabilities can have severe real-world consequences, a robust SELinux policy is non-negotiable.

Android leverages SELinux to isolate system services, applications, and hardware interfaces, preventing malicious or buggy code from compromising the entire system. Every process and file on an Android device has an associated SELinux context, a label that dictates its permissions. When a process attempts an action (e.g., reading a file, binding a socket) that is not explicitly allowed by the SELinux policy, the kernel generates an “Access Vector Cache” (AVC) denial. Understanding and resolving these denials is a core skill for anyone developing or maintaining Android embedded systems.

Understanding SELinux Denials

Anatomy of a Denial

An SELinux denial message, typically found in kernel logs, provides crucial information for debugging. It usually follows a pattern similar to this:

avc: denied { permission } for pid=PID comm="process_name" scontext=u:r:source_type:s0 tcontext=u:object_r:target_type:s0 tclass=target_class permissive=0

• permission: The specific action that was denied (e.g., `read`, `write`, `getattr`, `connect`).
• pid, comm: The Process ID and name of the process attempting the action (the subject).
• scontext: The SELinux context of the subject (the process).
• tcontext: The SELinux context of the target resource (e.g., file, device node, service).
• tclass: The class of the target resource (e.g., `file`, `chr_file`, `binder`, `service_manager`).
• permissive=0: Indicates the denial occurred in enforcing mode. If `permissive=1`, it would be a warning, not a block.

Identifying Denials

Denials are logged by the kernel. You can access these logs using standard Android debugging tools:

Using logcat

logcat is your primary tool for real-time log analysis. Filter for AVC denials:

adb logcat | grep "avc: denied"

This command will display any SELinux denials as they occur on the device. For persistent issues, you might need to run this while reproducing the problem.

Using dmesg

Kernel messages, including SELinux denials, are also available via `dmesg`. This is useful if the `logcat` buffer has rolled over or you need to inspect historical kernel messages directly:

adb shell dmesg | grep "avc: denied"

If you have root access and `audit` tools installed (common in AOSP builds), you can also look at `/sys/fs/pstore/console-ramoops` or use `auditd` if configured, though `logcat` and `dmesg` are usually sufficient for initial debugging.

Step-by-Step Debugging Methodology

Step 1: Reproduce the Denial

The first step is to consistently reproduce the action that triggers the denial. Clear your log buffer (`adb logcat -c`) and then perform the specific operation that fails. This ensures you capture only the relevant denials.

Step 2: Analyze the Denial Message

Once you have the denial message, break it down: identify the `scontext`, `tcontext`, `tclass`, and `permission`. These are the building blocks for your policy rule.

Step 3: Identify the Source Process

From the `comm` field, determine which application or service is attempting the unauthorized action. This helps you locate the relevant SELinux domain (`source_type`) for which you might need to add permissions.

Step 4: Determine the Target Resource

The `tcontext` and `tclass` tell you exactly what resource is being accessed. Is it a file, a character device, a Binder service, or something else? Understanding the target helps you determine the appropriate target type and class in your policy.

Resolving Denials: Crafting Custom SELinux Policies

Resolving denials involves modifying or extending your Android device’s SELinux policy. This typically means adding new Type Enforcement (TE) rules or updating file contexts.

Policy File Structure

SELinux policy files are primarily located under the AOSP `device/<vendor>/<board>/sepolicy` or `system/sepolicy` directories. Key file types include:

• `.te` files: Type Enforcement policy rules.
• `.fc` (file_contexts) files: Define SELinux labels for files and directories.
• `.rc` files: Android Init Language scripts, where services are started and can have their SELinux context explicitly set.

Writing Type Enforcement (TE) Rules

TE rules define the allowed interactions between contexts. The most common rule is `allow`:

allow source_type target_type:target_class { permissions };

• source_type: The domain of the process trying to perform the action.
• target_type: The type of the resource being accessed.
• target_class: The class of the resource (e.g., `file`, `chr_file`, `binder`).
• permissions: A space-separated list of allowed operations.

For example, if your custom IoT service `my_service` (with SELinux type `my_service_t`) needs to read a custom log file `/data/misc/mylogs/app.log` (which you’ve labeled `mylog_file_t`), a denial for `read` on `file` would lead to this rule:

allow my_service_t mylog_file_t:file { read getattr open };

It’s crucial to grant only the minimum necessary permissions (Principle of Least Privilege). Avoid `*` for permissions or broad `type` definitions.

Example: Accessing a Custom Peripheral Device

Let’s say your custom Android IoT application needs to communicate with a new sensor exposed as `/dev/my_sensor_device`. The application, running in a custom domain `my_app_domain_t`, is getting `avc: denied { open read write } for … scontext=u:r:my_app_domain_t:s0 tcontext=u:object_r:device:s0 tclass=chr_file`.

1. Define the device type in a `.te` file:

Create `device/<vendor>/<board>/sepolicy/vendor/my_device.te`:

type my_sensor_device_t, dev_type;

2. Label the device node in `file_contexts`:

Update `device/<vendor>/<board>/sepolicy/vendor/file_contexts` (or a dedicated `my_device_file_contexts`):

/dev/my_sensor_device    u:object_r:my_sensor_device_t:s0

3. Grant permissions in your app’s domain `.te` file:

Assuming your app runs in `my_app_domain_t`, modify `device/<vendor>/<board>/sepolicy/vendor/my_app_domain.te`:

allow my_app_domain_t my_sensor_device_t:chr_file { open read write ioctl getattr };

Remember to regenerate your policy and flash the updated image to the device.

Integrating with AOSP Build System

For custom `.te` files and `file_contexts`, ensure they are included in your device’s policy compilation. Typically, you’d add them to a `BOARD_SEPOLICY_DIRS` variable in your `BoardConfig.mk` or `device.mk`:

BOARD_SEPOLICY_DIRS +=     device/<vendor>/<board>/sepolicy/vendor

This ensures the AOSP build system picks up your custom policy definitions during compilation.

SELinux Policy Hardening Best Practices for Embedded Systems

Principle of Least Privilege

Always grant the minimum necessary permissions. Instead of `allow my_app_t *:file { * }`, be specific: `allow my_app_t my_data_file_t:file { read write getattr }`.

Avoid dontaudit in Production

While `dontaudit` rules (`dontaudit my_app_t some_type:file { read };`) can hide noisy denials during development, they should generally be removed for production builds. Denials indicate a potential security issue or policy gap; hiding them prevents proper auditing.

Use Specific Types

Resist the urge to use overly broad types like `unconfined_t` or `domain`. Create specific types for your custom services, devices, and files. This compartmentalizes risk.

Regular Audits

Periodically review your custom SELinux policies. As your system evolves, new interactions might arise, or old permissions might become unnecessary. Automated tools can help identify overly permissive rules.

Enforce Mode Always

Always run your production Android IoT devices in SELinux enforcing mode. Permissive mode (`setenforce 0`) should only be used temporarily during development and never in a deployed system, as it disables the core security benefits of SELinux.

Conclusion

Debugging and resolving SELinux denials on Android IoT devices is a critical skill for building secure and robust embedded systems. By systematically analyzing denial messages, understanding the SELinux policy structure, and applying the principle of least privilege when crafting custom rules, developers can effectively harden their devices against security threats. While challenging, a well-configured SELinux policy forms an indispensable layer of defense, ensuring the integrity and confidentiality of your Android-powered IoT solutions.