Introduction: Securing Android Automotive with SELinux

Android Automotive OS (AAOS) provides a rich, integrated infotainment experience in modern vehicles. Underlying its functionality is a robust security model, with SELinux (Security-Enhanced Linux) playing a pivotal role. SELinux enforces mandatory access control (MAC) policies, preventing unauthorized operations and containing potential security breaches. However, with each Android release, the SELinux policy framework evolves, becoming stricter and more modular. Migrating legacy SELinux policies, particularly those developed for Android 11 or earlier, to comply with Android 12+ standards for Automotive OS can be a significant challenge for OEMs and Tier-1 suppliers.

This article delves into the best practices for migrating and hardening SELinux policies in Android Automotive environments, focusing on the architectural changes introduced in Android 12+ and providing actionable steps to ensure compliance and robust security.

The Evolution of Android SELinux for Automotive

Project Treble, introduced in Android 8.0, fundamentally restructured Android, separating the Android framework from vendor implementations. This modularization extended to SELinux policies, introducing partition-specific policies for `vendor`, `system`, `product`, and `system_ext`. Android 12+ further refines this separation, aiming for a truly hermetic `system` partition and tightening restrictions on interactions between vendor-specific components and the core system.

Key architectural changes impacting SELinux policy migration include:

• Stricter `neverallow` Rules: Android 12+ significantly expands the set of `neverallow` rules, which are policy constraints that forbid certain access patterns. These rules are designed to prevent common security vulnerabilities and enforce the Treble interface separation. Violations of `neverallow` rules will cause policy compilation failures.
• Enhanced Policy Modularization: Policies are more strictly confined to their respective partitions. `vendor` policies should primarily define rules for `vendor` processes and types, similarly for `product` and `system_ext`. Direct dependencies on `system` internal types from `vendor` are heavily restricted.
• Introduction of `system_ext`: This partition allows device manufacturers to include system features without modifying the `system` partition. It also hosts device-specific SELinux policies that interact with the core framework, acting as a bridge for custom system services.
• Preference for `hwbinder` for HALs: While `binder` is used for communication within the system and between apps, `hwbinder` is the preferred IPC mechanism for Hardware Abstraction Layers (HALs) and vendor services. Android 12+ policies encourage and often require `hwbinder` for interactions with HALs, limiting direct `binder` usage from `vendor` to `system` services.

Step-by-Step Migration Guide for Legacy Policies

Migrating policies involves identifying violations, understanding the new structure, and refactoring rules.

Step 1: Identify Legacy Violations and Audit Logs

The first step is to compile your legacy policies against an Android 12+ build and analyze the errors. Policy compilation failures will often point to `neverallow` violations. For runtime issues, use `dmesg` or `adb logcat | grep audit` to identify SELinux denial messages.

Example `dmesg` output showing a denial:

audit: type=1400 audit(1678886400.000:123): avc: denied { read } for pid=1234 comm="my_vendor_service" name="some_sys_file" dev="sysfs" ino=5678 scontext=u:r:my_vendor_service_t:s0 tcontext=u:object_r:sysfs_type:s0 tclass=file permissive=0

Use `audit2allow` to get suggestions, but be critical. Do not blindly apply `audit2allow` output; it often suggests overly broad permissions.

adb shell dmesg | audit2allow -p platform/prebuilts/build-tools/linux-x86/bin/sepolicy

Step 2: Understand New Policy Structure and Placement

Custom policies should reside in the correct partition directories:

• `vendor/etc/selinux/` (e.g., `vendor_sepolicy`): For vendor-specific domains, types, and rules.
• `product/etc/selinux/` (e.g., `product_sepolicy`): For product-specific domains and types.
• `system_ext/etc/selinux/` (e.g., `system_ext_sepolicy`): For system extension services and types.

Avoid placing custom rules directly into `system/sepolicy` as this partition is designed to be immutable by OEMs.

Step 3: Refactor Type and Domain Definitions

Align your custom types with AOSP common types where possible. For instance, if you have a `my_log_daemon` type that is essentially a logging service, consider extending or specializing an existing AOSP type like `logd_service`. When defining new types, ensure they inherit from appropriate base types.

# Old (legacy) - potentially too broad or not aligned with AOSP structure
type my_vendor_app, domain;
type my_vendor_app_data_file, file_type;

# New (Android 12+) - explicitly define base types and roles
type my_vendor_app, appdomain, mlstrustedsubject;
type my_vendor_app_data_file, file_type, data_file_type;
file_type_auto_trans(my_vendor_app, my_vendor_app_data_file, { app_data_file });

Step 4: Address `neverallow` Rules

`neverallow` rules are the biggest hurdle. Common `neverallow` violations involve `vendor` components directly accessing `system` internal services or files without a well-defined interface.

Strategies to resolve `neverallow` violations:

• Use Stable APIs/HALs: If a vendor process needs `system` functionality, it should go through a stable API, a vendor-defined HAL, or a `system_ext` service.
• Delegate Permissions: Instead of granting direct access, delegate the sensitive operation to a trusted `system_ext` service or a properly defined HAL.
• Refactor Services: If a legacy vendor service provides functionality that is now considered ‘system-level’, consider moving it to `system_ext` and defining an appropriate interface for `vendor` components to interact with it.

Example of refactoring `vendor` accessing a `system` property:

# Legacy (likely to trigger neverallow on Android 12+)
allow my_vendor_app system_prop:property_service { set };

# New (via system_ext service or a custom property)
# Option A: Define a custom property in vendor_init.rc and allow my_vendor_app to set it
# In vendor.te
# type my_vendor_prop, property_type;
# property_type(my_vendor_prop);

# allow my_vendor_app my_vendor_prop:property_service { set };

# Option B: Use a system_ext service to mediate access
# Define a service in system_ext that can set the system_prop, and allow my_vendor_app to call that service.

Step 5: Transitioning from `binder` to `hwbinder` for HALs

For Hardware Abstraction Layers (HALs), Android 12+ strongly promotes `hwbinder`. If your legacy policy grants `binder_call` permissions from `vendor` processes to `system` services that are related to hardware, you likely need to transition to `hwbinder` and corresponding types.

How to transition:

1. Define `hwbinder` services: Ensure your HALs are registered as `hwbinder` services.
2. Update client policies: Grant `hwbinder_use` and `hwbinder_call` permissions instead of `binder_use` and `binder_call`.

# Old (binder for HALs - discouraged/restricted in 12+)
# allow my_vendor_hal_client system_server:binder { call };
# allow my_vendor_hal_client hal_foo_server:binder { call };

# New (hwbinder for HALs)
allow my_vendor_hal_client hwservice_manager:binder { call };
allow my_vendor_hal_client hal_foo_hwservice:hwservice_manager { find };
allow my_vendor_hal_client hal_foo_server:hwbinder { call transfer };

Step 6: Testing and Validation

After modifying policies, thorough testing is crucial.

• Policy Compilation: Always ensure your policies compile without errors.
• Boot Testing: Flash the new image and ensure the device boots correctly. Monitor `dmesg` and `logcat` for AVC denials.
• Functionality Testing: Verify all affected services and applications function as expected.
• Enforcing Mode: Always test in enforcing mode (`setenforce 1`). Testing in permissive mode (`setenforce 0`) only logs denials without enforcing them, potentially masking issues.
• `seapp_contexts` and `file_contexts`: Verify that `seapp_contexts` correctly assigns SELinux types to applications and that `file_contexts` properly labels files created by your components.

Advanced Debugging Techniques

• `sesearch`: A powerful tool to query compiled SELinux policy. Helps understand existing rules and potential conflicts.
• `auditctl`: Can temporarily add rules or modify audit behavior on a running system for quick debugging, though not for permanent solutions.
• Per-process `dmesg` filtering: To isolate denials from a specific process, use `adb shell dmesg | grep ‘comm=”my_process”‘`.
• `avc_info`: Android provides `avc_info` for detailed debugging of access vector cache entries.

Conclusion: A More Secure Automotive Future

Migrating legacy SELinux policies to Android 12+ standards for Automotive OS is a non-trivial but essential task. It demands a deep understanding of the evolving Android security architecture, particularly the stricter modularity, `neverallow` rules, and the shift towards `hwbinder` for HALs. By systematically identifying violations, refactoring policies to align with partition boundaries, leveraging stable interfaces, and thoroughly testing, OEMs can ensure their Android Automotive implementations are not only feature-rich but also robustly secure, ready for the challenges of an increasingly connected and security-conscious automotive landscape.