Introduction to Mandatory Access Control in Android

Mandatory Access Control (MAC) is a fundamental security concept, critical for enforcing system integrity and confidentiality. In the Android ecosystem, SELinux (Security-Enhanced Linux) is the most widely recognized and extensively used MAC framework. It operates by labeling every process and file with an SELinux context and then enforcing rules defined in a policy to restrict interactions. While SELinux is robust and comprehensive, relying solely on its visibility can create blind spots for security researchers and system hardenings experts. The premise of “hidden” MACs goes beyond SELinux, exploring other enforcement mechanisms that might operate at different layers of the Android stack or in parallel with SELinux.

Understanding these supplementary MACs is crucial because they often represent vendor-specific customizations, proprietary security enhancements, or lower-level kernel hooks that can significantly impact device security. Uncovering them can reveal additional attack surfaces, bypass opportunities, or undocumented security features, making advanced reverse engineering a necessity for a complete security posture assessment.

The Linux Security Module Framework: Beyond SELinux

The Linux Security Module (LSM) framework provides a generalized mechanism for security-aware kernel code to query a loaded security module for an access decision. SELinux is merely one implementation of an LSM. The kernel supports LSM stacking, meaning multiple LSMs can be active simultaneously, with each module contributing to the overall access decision. This allows vendors to implement custom security policies or augment existing ones without necessarily modifying the core SELinux policy.

Identifying Active LSMs

The first step in uncovering non-SELinux MACs is to identify which LSMs are currently active on a device. The kernel command line often specifies loaded LSMs. You can inspect this using cat /proc/cmdline. Additionally, the /sys/kernel/security/ directory provides insights into loaded security modules.

adb shell cat /proc/cmdline | grep -o 'lsm=[^ ]*'adb shell ls -l /sys/kernel/security/

The output might show lsm=selinux,lockdown,yama indicating that SELinux, Lockdown, and Yama are active. Custom vendor LSMs might appear here or be integrated more subtly. If you see an unfamiliar LSM, it warrants deeper investigation.

Reverse Engineering Custom LSMs

For custom LSMs, the process involves analyzing the kernel. If kernel source code is available (e.g., AOSP or vendor open-source projects), search for calls to security_register_lsm(). This function registers an LSM with the kernel. You can find these in drivers/security/ or vendor-specific kernel modules.

grep -r "security_register_lsm" drivers/security/

Without source, you’ll need to analyze the kernel binary (vmlinux). Tools like IDA Pro or Ghidra can be used to disassemble the kernel and search for references to security_register_lsm. Once identified, analyze the custom LSM’s hooks (e.g., task_alloc_security, inode_permission, socket_create) to understand what resources and operations it restricts. These hooks are functions within the LSM that get called by the kernel before allowing an operation, providing a point for custom policy enforcement.

Binder IPC Policy Enforcement: The Service Manager’s Role

Binder is the cornerstone of inter-process communication (IPC) in Android. While SELinux policies control Binder transactions at a coarse grain (e.g., which domain can call which Binder service), fine-grained access control often resides within the Binder services themselves or within the servicemanager. This forms another critical layer of MAC enforcement, often overlooked when focusing solely on SELinux.

Android’s servicemanager, the central Binder service, maintains a registry of services and performs initial checks. However, many services implement their own permission checks using APIs like Context.checkCallingOrSelfPermission() or Context.enforcePermission(). These checks rely on Android’s manifest permissions, but custom permissions or internal logic can also be employed.

Analyzing Binder Transactions for Custom Checks

To uncover these hidden Binder-level policies, observe Binder traffic and decompile relevant applications or framework services. Tools like strace or ftrace can log Binder calls and returns, revealing which services are being accessed and which permissions are being checked.

adb shell strace -f -e trace=binder_call,binder_return /system/bin/app_process32 /system/bin com.android.commands.am.Am statusbar expand-notifications

This command traces Binder calls made by the Am command when interacting with the status bar. By observing the arguments and return values, you can infer permission checks. For deeper analysis, decompile the relevant APKs (e.g., SystemUI.apk, framework.jar) using tools like Jadx or Apktool. Search for usages of checkCallingPermission, enforceCallingPermission, or custom permission strings. Custom logic within these methods can reveal non-standard access control mechanisms specific to a vendor or service.

Furthermore, some vendors might implement custom hooks within the Binder driver itself, or modify the binder_security_policy, which existed before LSM stacking for Binder-specific security. Analyzing the Binder driver source or binary (if available) can reveal these low-level modifications.

Practical Reverse Engineering Steps

Device Preparation

To perform this level of reverse engineering, you typically need a rooted device with an unlocked bootloader. This allows full access to the file system, kernel memory, and the ability to flash custom images or tools. Obtain the device’s boot.img and system.img to extract the kernel and userspace components for offline analysis.

Kernel Analysis

1. **Extract Kernel:** Use tools like Adb-Image-Tools or magiskboot to extract the kernel image (vmlinux) from boot.img.

magiskboot unpack boot.img

2. **Disassemble Kernel:** Load the extracted vmlinux into a disassembler/decompiler like IDA Pro or Ghidra. Search for cross-references to security_register_lsm to locate potential custom LSMs. Also, look for calls to core kernel security hooks (e.g., security_inode_permission, security_mmap_file) and identify the specific LSM functions called. Analyze relevant vendor kernel modules (often in /vendor/lib/modules) for security-related code. Additionally, review dmesg output on a running device for any security-related messages during boot that might indicate custom LSM initialization.

Userspace Component Analysis

1. **Extract System/Vendor Apps:** Pull relevant APKs and JARs from /system/app, /system/priv-app, /system/framework, and /vendor/app.

adb pull /system/framework/framework.jar.adb pull /system/priv-app/SystemUI/SystemUI.apk .

2. **Decompile and Analyze:** Use Jadx or Apktool to decompile these components. Search for APIs related to permissions and access control. Pay close attention to calls to checkCallingPermission, enforcePermission, or any custom permission-checking methods within vendor services. Look for custom permission strings defined in AndroidManifest.xml files that are not part of the standard Android SDK, as these often point to vendor-specific MACs.

Conclusion

While SELinux provides a robust foundational MAC framework for Android, relying solely on its visibility can leave significant gaps in security assessments. By reverse engineering and analyzing custom Linux Security Modules, granular Binder IPC policy enforcements, and vendor-specific kernel and userspace modifications, security professionals can uncover a broader spectrum of hidden MAC mechanisms. This expert-level approach to security analysis is vital for truly understanding a device’s security posture, identifying potential vulnerabilities, and implementing comprehensive hardening strategies beyond standard Android security practices.