Introduction: The SELinux Imperative in Custom ROMs

Porting Android Open Source Project (AOSP) based devices to custom ROMs like LineageOS is a rewarding endeavor for developers and enthusiasts alike. It offers a chance to extend device lifespan, improve performance, and enjoy a more feature-rich or privacy-focused experience. However, this journey is often fraught with subtle yet critical challenges, none more enigmatic and security-sensitive than System-Wide Enforced Linux (SELinux) policies. While AOSP provides a robust foundation, LineageOS often implements a more stringent, finely-tuned SELinux policy set. This article delves into these differences, providing an expert-level guide to identify, debug, and resolve SELinux denials, ensuring your custom ROM port boots securely in enforcing mode.

SELinux Fundamentals: Enforcing, Permissive, and Android Security

SELinux is a mandatory access control (MAC) security mechanism embedded in the Linux kernel. Unlike traditional discretionary access control (DAC) where users or programs can grant their own permissions, MAC operates on a principle of least privilege, requiring explicit permission for every action. In Android, SELinux policies define what processes (domains) can access what resources (types), such as files, sockets, and IPC services.

• Enforcing Mode: In this mode, all unauthorized actions are blocked, and an AVC (Access Vector Cache) denial is logged. This is the desired and secure state for any production Android device.
• Permissive Mode: In this mode, unauthorized actions are logged but not blocked. While useful for debugging, running a device in permissive mode significantly compromises its security, making it vulnerable to exploits.

Android’s security model heavily relies on SELinux to sandbox applications, protect system services, and prevent privilege escalation. A properly configured SELinux enforcing policy is non-negotiable for a secure custom ROM.

AOSP vs. LineageOS: Divergent SELinux Policy Philosophies

While both AOSP and LineageOS operate on the same SELinux core principles, their policy implementations can differ significantly, particularly in how they handle device-specific hardware access and third-party vendor blobs.

• AOSP Baseline: AOSP provides a generic set of SELinux policies that aim for broad compatibility across various hardware. These policies serve as a good starting point but often lack the granular specificity required for unique device architectures or specific peripheral interactions.
• LineageOS Refinements: LineageOS builds upon AOSP but often introduces stricter neverallow rules and more specific type definitions. Its policies are frequently updated to align with the latest Android security enhancements and to tighten security around common vulnerabilities. This rigorous approach, while enhancing security, means that policies that worked perfectly fine on an AOSP build might cause boot failures or hardware malfunctions on LineageOS due to stricter enforcement or different context definitions for certain resources or services. For instance, a vendor HAL might require specific permissions to access a `/dev` node that is implicitly allowed in AOSP but explicitly denied or has a different type in LineageOS.

The core challenge in porting lies in bridging these policy gaps to allow device-specific functionalities to operate correctly under LineageOS’s often tighter security constraints.

Common SELinux Denials During a LineageOS Port

When porting, expect to encounter various AVC denials. Some common scenarios include:

• init-Related Failures: The init process is critical for booting. Denials here often relate to creating directories, mounting filesystems, or setting up device nodes with incorrect contexts. For example, access to partitions like `/dev/block/bootdevice/by-name/persist` might be denied.
• Hardware Access Issues: Components like camera, sensors, audio, display, or proprietary peripherals often involve vendor HALs (Hardware Abstraction Layers) interacting with device nodes in `/dev`. These interactions require specific SELinux permissions.
• Vendor Blob Interactions: Closed-source vendor binaries (blobs) often expect certain file contexts or permissions that might not align with LineageOS policies, leading to services crashing or failing to start.
• System Services: Critical Android services like mediaserver, audioserver, cameraserver, or hwservicemanager failing to start due to denied resource access.

Step-by-Step: Debugging SELinux Denials

Debugging SELinux is an iterative process of identifying denials, understanding their cause, and crafting appropriate policy rules.

1. Initial Boot in Permissive Mode

To identify all initial boot-time denials without blocking the boot process, start your port in permissive mode. Add the following to your device’s BoardConfig.mk:

BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive

After building and flashing, verify the mode:

adb shell getenforce

It should return Permissive.

2. Capturing AVC Denials

With the device running in permissive mode, all denied actions will be logged. The primary tools for capturing these are logcat and dmesg:

adb logcat | grep audit

or

adb shell dmesg | grep avc

You’ll see messages formatted like: avc: denied { } for pid= comm=