AOSP Security with SELinux

Android Open Source Project (AOSP) has robust security mechanisms, with Security-Enhanced Linux (SELinux) playing a crucial role in enforcing access control. AOSP security relies on SELinux to implement Mandatory Access Control (MAC) rather than traditional Discretionary Access Control (DAC), which relies on user permissions. Integrated into Android since version 4.3, SELinux operates in either permissive mode (logging violations) or enforcing mode (blocking unauthorized actions). Strong Application Security in Android depends heavily on properly configured SELinux policies that restrict unauthorized interactions between processes and system resources.

For embedded developers working on middleware, HAL, and system daemons, understanding SELinux policy writing for Android AOSP is critical for securing Android devices. Proper SELinux configuration prevents privilege escalation, restricts unauthorized access, and protects sensitive system components. This blog explores how SELinux works within AOSP security, best practices for defining security policies, and a practical example of applying SELinux to a Binderized HAL. By mastering SELinux policy writing for Android AOSP, developers can fortify embedded systems against exploits and security breaches.

What is SELinux?

SELinux is a security architecture integrated into the Linux kernel, providing mandatory access control embedded Linux policies that restrict programs' capabilities beyond traditional discretionary access controls (DAC). It ensures that even if an application is compromised, its actions remain confined within predefined boundaries. Mandatory access control embedded Linux implementations like SELinux are fundamental to AOSP security in production Android devices.

Core Concepts of SELinux

• Labels: Every process and object (like files, directories, and ports) in the system is assigned a security label. These labels are central to SELinux's decision-making process.
• Type Enforcement (TE): This is the primary mechanism of SELinux, where policies define how types (labels) associated with processes can interact with types associated with objects. For instance, a process labeled as httpd_t (Apache) can be restricted to accessing only files labeled as httpd_sys_content_t.
• Roles and Users: SELinux defines roles and users to manage permissions more granularly. However, in many implementations, type enforcement remains the primary focus.

SELinux in AOSP

Integration of SELinux in Android

Google integrated SELinux into Android starting from version 4.3 to bolster AOSP security. In AOSP, SELinux operates in two modes:

• Permissive Mode: SELinux policies are not enforced; violations are logged but not prevented.
• Enforcing Mode: SELinux policies are enforced, and violations are both logged and blocked. Android devices aim to operate in enforcing mode to ensure robust security.

Benefits of SELinux in Android

• Mitigation of Privilege Escalation: Even if an application gains unauthorized privileges, SELinux confines its actions, preventing broader system compromises. This is a key Application Security benefit.
• Protection Against Malware: SELinux policies can restrict applications from accessing sensitive data or system components, reducing malware's potential impact on AOSP security.
• Enhanced Multi-User Security: By enforcing strict access controls, SELinux ensures that user data remains isolated and protected from other users and applications.

Implementing SELinux in AOSP

Setting Up SELinux

• Kernel Configuration: Ensure that the Linux kernel is compiled with SELinux support. This involves enabling specific configuration options related to security modules.
• Filesystem Labeling: Assign appropriate security labels to filesystem objects. This can be achieved using tools like restorecon or by setting default labels in filesystem images.
• Policy Compilation: Write SELinux policies tailored to your system's requirements and compile them using tools like checkpolicy.
• Policy Loading: Load the compiled policies into the kernel using tools such as load_policy or by integrating them into the system's initialization process.

Writing SELinux Policies

SELinux policy writing for Android AOSP is especially important in automotive embedded systems where Android Automotive OS (AAOS) runs multiple critical services, including IVI (In-Vehicle Infotainment), ADAS (Advanced Driver Assistance Systems), and Telematics. Ensuring AOSP security in such a system requires SELinux policies to enforce strict access controls across system components, particularly middleware services, Binderized HALs, and system daemons. Our Product Engineering Services and Embedded Device Driver Development ensure secure, SELinux-compliant Android systems with robust low-level control. Below, we'll map SELinux policy writing for Android AOSP to a real-world automotive example using a Binderized HAL for vehicle data access, ensuring that only authorized system components can retrieve and modify vehicle information.

Identify Domains and Types

In an automotive system, consider a Vehicle HAL (VHAL), which provides access to vehicle-related data such as speed, fuel levels, engine status, and door lock state. The Vehicle HAL service interacts with system components like the IVI system, navigation app, and telematics module. The Android vehicle HAL security implementation defines which domains are permitted to call into vehicle data interfaces.

• The Vehicle HAL daemon runs in the hal_vehicle_t domain.
• Vehicle data files are labeled as vehicle_data_t.
• The IVI system runs in the ivi_system_t domain.
• The Telematics service operates in the telematics_t domain.

Defining these domains ensures controlled access between different system components, preventing unauthorized applications from accessing critical vehicle parameters.

type hal_vehicle_t;  // Domain for the Vehicle HAL service
type vehicle_data_t; // Label for vehicle data files
type ivi_system_t;   // Domain for IVI system
type telematics_t;   // Domain for Telematics service

Define Access Rules

Now, define access rules to ensure that only authorized services can communicate with the Vehicle HAL and access vehicle data.

• The IVI system needs to read vehicle speed data for real-time display.
• The Telematics module can read engine status but should not modify any data.
• Unauthorized apps, such as a third-party music player, should not access vehicle data.

Example SELinux rules

• Allow the IVI system to read vehicle speed data:

  allow ivi_system_t vehicle_data_t:file read;
  

• Allow the telematics module to read engine status but prevent modifications:

  allow telematics_t vehicle_data_t:file read;
  deny telematics_t vehicle_data_t:file write;
  

• Restrict third-party applications from accessing vehicle data:

  deny untrusted_app_t vehicle_data_t:file { read write };
  

• Ensure secure Binder communication between Vehicle HAL and IVI system:

  allow hal_vehicle_t ivi_system_t:binder call;
  allow hal_vehicle_t system_server:service_manager find;
  

This configuration ensures that only authorized system components can retrieve vehicle-related information, reducing security risks and strengthening Application Security at the HAL boundary.

Use Macros and Templates

Instead of defining repetitive policies, leverage SELinux macros to simplify SELinux policy writing for Android AOSP. Example macro to allow read access for trusted system components:

r_file(ivi_system_t, vehicle_data_t)
r_file(telematics_t, vehicle_data_t)

Macro to restrict modification of vehicle data:

d_file(telematics_t, vehicle_data_t)

These macros improve policy readability and maintainability, ensuring consistent security enforcement.

Test Policies in Permissive Mode

Before enforcing SELinux policies, test them in permissive mode to verify correctness.

1. Enable permissive mode for Vehicle HAL:

   permissive hal_vehicle_t;
   

2. Monitor SELinux logs using logcat or dmesg to check for denied access attempts:

   adb shell dmesg | grep avc
   

   Example log entry:

   avc: denied { read } for pid=3456 comm='telematics_service' name='vehicle_data'
   

3. Adjust policies based on logs before enforcing them:

   setenforce 1  # Enable enforcing mode
   

By iterating through this process, developers ensure that only trusted automotive services access critical vehicle data, securing the system against potential data leaks or unauthorized modifications.

Tools and Resources

• SELinux Notebook: An open-source resource that provides comprehensive insights into SELinux concepts and implementations. GitHub - SELinuxProject/selinux-notebook
• SELinux Policy Guide: A visual guide that offers practical examples and explanations on SELinux policy enforcement. Your visual how-to guide for SELinux policy enforcement | Opensource.com
• NSA's SELinux Implementation Report: An in-depth report detailing the implementation of SELinux as a Linux Security Module. Implementing SELinux as a Linux Security Module

Conclusion

Integrating SELinux into AOSP significantly strengthens the AOSP security posture of Android devices. By mastering SELinux policy writing for Android AOSP, developers can ensure strong Application Security — applications operate within defined boundaries, safeguarding user data and maintaining system integrity. The Android vehicle HAL security implementation patterns shown here are directly applicable to automotive and industrial Android deployments. Embracing SELinux not only aligns with embedded security best practices but also reinforces trust in the Android ecosystem.