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. Unlike traditional Discretionary Access Control (DAC), which relies on user permissions, SELinux implements Mandatory Access Control (MAC) to restrict system interactions based on predefined policies. Integrated into Android since version 4.3, SELinux operates in either permissive mode (logging violations) or enforcing mode (blocking unauthorized actions).

For embedded developers working on middleware, HAL, and system daemons, understanding SELinux policies, labels, and domains 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, best practices for defining security policies, and a practical example of applying SELinux to a Binderized HAL. By mastering SELinux, 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 (MAC) 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.

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 the platform's 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.
• Protection Against Malware: SELinux policies can restrict applications from accessing sensitive data or system components, reducing malware's potential impact.
• 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

In an automotive embedded system, Android Automotive OS (AAOS) runs multiple critical services, including IVI (In-Vehicle Infotainment), ADAS (Advanced Driver Assistance Systems), and Telematics. Ensuring security in such a system requires SELinux policies to enforce strict access controls across system components, particularly middleware services, Binderized HALs, and system daemons. Below, we’ll map SELinux policy writing 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 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.

Use Macros and Templates

Instead of defining repetitive policies, leverage SELinux macros to simplify policy writing. 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.

• Enable permissive mode for Vehicle HAL:

permissive hal_vehicle_t;        

• 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'        

• 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 security posture of Android devices. By understanding and implementing SELinux policies effectively, developers can ensure that applications operate within defined boundaries, safeguarding user data and maintaining system integrity. Embracing SELinux not only aligns with best security practices but also reinforces trust in the Android ecosystem.

Reference:

AOSP Security with SELinux