Introduction: The Imperative of SELinux in Android Automotive

Android Automotive is rapidly becoming the operating system of choice for in-vehicle infotainment (IVI) and critical vehicle functions. While it offers a rich application ecosystem, the direct interaction with vehicle hardware poses significant security challenges. This is where Security-Enhanced Linux (SELinux) plays a pivotal role, enforcing mandatory access control (MAC) policies to protect system resources from unauthorized access. For the Vehicle Hardware Abstraction Layer (VHAL), which is the primary interface between Android services and the vehicle’s underlying hardware, robust SELinux policies are not just good practice—they are essential for safety and security. This article delves into defining advanced custom SELinux policies to secure custom VHAL implementations, ensuring fine-grained control over vehicle interactions.

Understanding VHAL and Its Security Context

The VHAL is a crucial component in Android Automotive, standardizing the interface for interacting with vehicle properties (e.g., speed, gear, HVAC controls). It allows Android applications and services to query and control vehicle hardware without needing direct hardware-specific drivers. By default, Android provides a set of SELinux policies to protect the core VHAL service and its interactions. However, vehicle manufacturers and Tier 1 suppliers often introduce custom hardware features, requiring new VHAL properties and services. These customizations necessitate tailored SELinux policies to prevent malicious or buggy applications from gaining unauthorized access to critical vehicle functions.

Identifying VHAL processes and their default contexts is the first step. Typically, the primary VHAL service runs under a domain like vehicle_hal_service. You can inspect running processes and their contexts using ps -Z:

adb shell
ps -Z | grep vehicle

This command would show entries similar to:

u:r:vehicle_hal_service:s0 system    1234  1 system/bin/[email protected]

This output confirms the SELinux domain (vehicle_hal_service) under which the VHAL process operates. Any new VHAL service or hardware component will need its own distinct and secure context.

The Need for Custom SELinux Policies in Automotive

While Android’s default SELinux policies provide a strong baseline, they cannot anticipate every custom hardware integration or specific OEM requirement. Integrating a new sensor, a unique vehicle control module, or a proprietary communication protocol often means extending the VHAL. Without custom policies, these new interfaces might either run with overly permissive default contexts (creating security holes) or be denied access entirely (breaking functionality). Crafting precise, least-privilege SELinux rules is critical to:

• Isolate custom VHAL components: Prevent compromise of one component from affecting others.
• Protect vehicle critical functions: Ensure only authorized software can control safety-critical systems.
• Enforce data privacy: Limit access to sensitive vehicle data.
• Maintain system integrity: Guard against unauthorized modifications to VHAL implementation.

Core SELinux Concepts for Android Policy Development

Before diving into policy creation, a brief refresher on key SELinux concepts:

• Type Enforcement (TE): The core of SELinux, defining how subjects (processes) of a certain type can access objects (files, sockets, services) of another type.
• Context: A label applied to every subject and object, consisting of user, role, type, and sensitivity (e.g., u:r:vehicle_hal_service:s0). The type is the most significant part for TE.
• Policy Files:
• .te (Type Enforcement): Defines types, domains, and rules for interactions.
• file_contexts: Maps file paths to their SELinux types.
• hwservice_contexts: Maps AIDL/HIDL services to their SELinux types.
• seapp_contexts: Maps Android applications (by UID/package) to their SELinux types.

Step-by-Step Custom Policy Definition for a New VHAL Module

Let’s consider a hypothetical scenario: we’re integrating a custom vehicle lighting controller, exposed via a new VHAL service and interacting with a specific device node /dev/custom_lighting_ctl.

1. Define a New Domain for Your Custom VHAL Service

First, create a new SELinux type for your custom VHAL service. This ensures it runs in its own isolated security domain. Create a .te file, for example, my_lighting_vhal.te, in your device’s device/<vendor>/<device>/sepolicy/ or a similar custom policy directory.

# my_lighting_vhal.te

type my_lighting_vhal_service, domain;
type my_lighting_vhal_service_exec, exec_type, file_type, vendor_file_type;

init_daemon_domain(my_lighting_vhal_service)

# Allow access to vehicle_hal_service for properties
alwaysallow my_lighting_vhal_service vehicle_hal_service:service_manager find;

# Allow logging and basic system interactions
allow my_lighting_vhal_service logd:dir search;
allow my_lighting_vhal_service logd:sock_file write;
allow my_lighting_vhal_service system_file:file execute_no_trans;
allow my_lighting_vhal_service self:capability { sys_nice chown setuid setgid };
allow my_lighting_vhal_service default_prop:property_service set;
allow my_lighting_vhal_service debugfs:file r_file_perms;
allow my_lighting_vhal_service vendor_file:dir r_dir_perms;
allow my_lighting_vhal_service vendor_file:file r_file_perms;

Explanation:

• my_lighting_vhal_service: The new domain type for our service.
• my_lighting_vhal_service_exec: The file type for its executable.
• init_daemon_domain: A macro that provides common permissions for services started by init.
• alwaysallow my_lighting_vhal_service vehicle_hal_service:service_manager find;: Crucial for a VHAL service, allowing it to register itself with or find the main vehicle_hal_service.

2. Define Object Types for Custom Hardware

Next, define types for any new hardware devices your VHAL service interacts with. For our /dev/custom_lighting_ctl device, add to my_lighting_vhal.te (or a new file like hw_types.te):

# In my_lighting_vhal.te or a common hw_types.te
type custom_lighting_device, dev_type;

3. Grant Specific Permissions to Your Custom VHAL Service

Now, grant your my_lighting_vhal_service domain access to the custom_lighting_device. Add to my_lighting_vhal.te:

# Allow my_lighting_vhal_service to read/write to the custom device
allow my_lighting_vhal_service custom_lighting_device:chr_file { create_file_perms rw_file_perms };

This rule specifies that processes in the my_lighting_vhal_service domain can perform read and write operations on character device files labeled custom_lighting_device.

4. Update file_contexts for Executables and Devices

You need to map your service’s executable and the device node to their respective SELinux types. Modify file_contexts (e.g., device/<vendor>/<device>/sepolicy/vendor/file_contexts):

# For the custom VHAL service executable
/vendor/bin/my_lighting_vhal_service u:object_r:my_lighting_vhal_service_exec:s0

# For the custom hardware device node
/dev/custom_lighting_ctl u:object_r:custom_lighting_device:s0

Ensure these paths correctly reflect where your service executable and device node will reside on the target system.

5. Update hwservice_contexts for HIDL/AIDL Services

If your custom VHAL component exposes a new HIDL or AIDL service, you must label it. For instance, if your service is named [email protected]/default, add to hwservice_contexts:

# Custom VHAL lighting service
[email protected]::ICustomLighting/default u:object_r:my_lighting_vhal_service:s0

6. Build and Flash Your Custom Policies

To integrate these policies into your Android Automotive build, ensure your .te files and updated _contexts files are included in the Android build system. Typically, you’d add your .te file to BOARD_SEPOLICY_DIRS in your BoardConfig.mk, or place it in an existing policy directory that gets compiled. The `_contexts` files are usually included automatically if they are in the standard locations.

After modifying policy files, rebuild your Android image (e.g., boot.img, vendor.img, or system.img depending on where the VHAL service and policies reside). Flash the new images to your device:

source build/envsetup.sh
lunch <your_device_target>
make -j$(nproc)

# Assuming vendor partition update
adb reboot bootloader
fastboot flash vendor <path_to_vendor_image.img>
fastboot reboot

Debugging SELinux Denials

After flashing, monitor for SELinux denials using logcat or dmesg:

adb logcat | grep 'avc: denied'
adb shell dmesg | grep 'avc: denied'

An example denial might look like:

avc: denied { read } for pid=1234 comm="my_lighting_vhal" name="custom_lighting_ctl" dev="tmpfs" ino=5678 scontext=u:r:my_lighting_vhal_service:s0 tcontext=u:object_r:custom_lighting_device:s0 tclass=chr_file permissive=0

This denial clearly shows my_lighting_vhal_service (source context) was denied read access to custom_lighting_ctl (target object) of type chr_file (target class) with target context custom_lighting_device. You would then add the missing permission to your my_lighting_vhal.te file:

allow my_lighting_vhal_service custom_lighting_device:chr_file read;

While audit2allow can suggest rules, it’s best used cautiously and manually reviewed, as it can generate overly broad policies. Always adhere to the principle of least privilege.

Best Practices for SELinux Policy Development

• Principle of Least Privilege: Grant only the minimum permissions necessary for your service to function.
• Granularity: Define specific types for specific resources. Avoid reusing broad types for critical components.
• Layered Approach: Separate policies for platform, vendor, and OEM components to maintain modularity.
• Thorough Testing: Test all use cases, including edge cases and error conditions, to ensure all necessary permissions are granted and no unintended accesses are allowed.
• Audit Logs: Regularly review SELinux audit logs (avc: denied messages) during development and testing.

Conclusion

Securing the VHAL in Android Automotive with custom SELinux policies is a critical step in building robust, safe, and secure in-vehicle systems. By carefully defining new security domains, labeling custom hardware, and granting precise permissions, developers can ensure that custom vehicle interactions are tightly controlled, mitigating risks from malicious applications or system vulnerabilities. Mastering these advanced SELinux techniques is indispensable for anyone working at the forefront of automotive software development.