Understanding SELinux in Android AOSP: Security at its Core (Part 2)

In Part 1 of this series, we introduced SELinux, its role in Android security, and its error-handling mechanisms. Now, let's dive into a real-world example, break down an AVC denial, and learn how to resolve SELinux policy issues to achieve the desired application behavior.

Forcing and Fixing a Policy Denial with simple example

Imagine we have an Android application that attempts to control the device's flashlight by writing to the file /sys/class/leds/flashlight/brightness. However, SELinux steps in and prevents this action, resulting in an AVC denial. Our goal is to understand why this happens and modify the SELinux policy to grant our application the necessary permission.

Code Snippet:

Absolutely! Let's integrate this new AVC denial into the article to illustrate the concepts further.

Understanding the AVC Denial Log

Let's analyze a real AVC denial that might occur in our flashlight example or a similar scenario. Here's a sample log entry:

Here's a breakdown of the crucial components:

• type=1400 audit(0.0:4887): This identifies the entry as an SELinux audit log.
• avc: denied { search }: SELinux blocked the "search" permission. This often implies an attempt to list the contents of a directory.
• uid=10132: The user ID of the process responsible for the action.
• name="leds" dev="sysfs" ino=17252: The target directory within the /sysfs filesystem.
• scontext=u:r:untrusted_app:s0:c132,c256,c512,c768: The security context of the app; notice it's labeled as untrusted_app.
• tcontext=u:object_r:sysfs_leds:s0: The security context of the target directory.
• tclass=dir: Confirms that the target is a directory.
• permissive=0: Indicates that SELinux is running in enforcing mode (actively blocking violations).
• app=com.sdcode.selinuxexample: The package name of the offending app.

Explanation

This AVC denial tells us that an app, likely com.sdcode.selinuxexample, categorized as "untrusted", is attempting to look inside the /sysfs/leds directory. However, the current SELinux policy doesn't allow untrusted applications to 'search' within this sensitive area.

SELinux Policy Syntax (Simplified)

SELinux policies are written in a specialized language. The core concept revolves around defining permissions:

allow source_domain target_type:class permission;

• source_domain: The context of the process trying to perform an action.
• target_type: The context of the file or resource.
• class: The type of object (file, directory, socket, etc.).
• permission: The action (read, write, open, etc.).

Fixing the Denial

1. Policy Modification: App need this permission, we can craft a policy rule like: allow untrusted_app sysfs_leds:dir { search };
2. Apply the Change: Choose between rebuilding the system image, using sepolicy-inject (if available), or issuing appropriate chcon commands for temporary testing.

• Specificity: AVC denials provide fine-grained details about the blocked action, the process, and the resource, easing troubleshooting.
• Security Context: The labels assigned to the app (untrusted_app) and the resource it's targeting (sysfs_leds) are vital clues for understanding and resolving the restriction.

audit2alow

If you encounter SELinux denials and find it challenging to write SELinux policy rules to address them, you can leverage the audit2allow tool to streamline the troubleshooting process. audit2allow parses system logs containing AVC (Access Vector Cache) denials, such as those found in adb logcat output or /var/log/audit/audit.log, and generates suggestions for SELinux policy rules that would allow the previously blocked actions.

1. Collect Relevant AVC Denials

First, gather the relevant AVC denial messages from system logs. You can use tools like adb logcat to capture denials related to your application's activities. For example:

adb logcat | grep avc: > avc_denials.txt

This command filters the adb logcat output to include only lines containing "avc:" (AVC denials) and saves them to a text file named avc_denials.txt for further processing.

2. Generate Policy Suggestions

Next, use audit2allow to analyze the collected AVC denials and generate policy suggestions. audit2allow analyzes the denials and produces SELinux policy snippets that, when applied, would allow the actions previously blocked by SELinux.

audit2allow -i avc_denials.txt -o suggested_policy.te

This command takes the input file avc_denials.txt containing AVC denial messages and outputs the suggested SELinux policy rules to a file named suggested_policy.te.

3. Review and Apply Policy Suggestions

Review the generated SELinux policy snippets in suggested_policy.te. Each snippet represents a rule that grants specific permissions to processes or domains to perform actions that were previously denied.

$ cat suggested_policy.te

After reviewing the policy suggestions, you can incorporate them into your SELinux policy configuration.

Conclusion

In our hands-on example, we've shown how SELinux keeps Android secure. By looking closely at AVC denials, learning about SELinux policy basics, and using tools like audit2allow, we can fix problems and adjust policies to balance security and app features.

Remember, SELinux is powerful but can be tricky. This article is just the start. As you work on Android apps or customize your system, understanding how to handle policy denials and make effective rules will prove invaluable.