Introduction to AppArmor on Android

AppArmor, a Linux Security Module (LSM), provides Mandatory Access Control (MAC) by confining programs to a limited set of resources. Unlike Discretionary Access Control (DAC) that relies on user and group IDs, AppArmor proactively restricts what an application can do, irrespective of its user context. While Android’s standard sandboxing mechanisms (UID/GID separation, SELinux) offer robust protection, integrating AppArmor allows for an even finer-grained security posture, especially pertinent for custom ROM developers, security enthusiasts, or those seeking to harden specific applications on rooted devices.

This guide will walk you through the advanced process of creating custom AppArmor profiles for Android applications, transforming your understanding of application security from a reactive to a proactive stance.

Prerequisites for AppArmor Profile Creation

Before diving into profile creation, ensure your environment meets these critical requirements:

• Rooted Android Device: Full access to the filesystem and superuser privileges are essential.
• Custom Kernel with AppArmor Support: Your device’s kernel must be compiled with AppArmor enabled. You can verify this by checking /proc/config.gz (if available) or using dmesg.
• ADB (Android Debug Bridge): Essential for interacting with your device from a desktop.
• Text Editor: For crafting the AppArmor profile files.
• Basic Linux Command Line Knowledge: Familiarity with commands like ls, grep, cat, and file manipulation.

To confirm AppArmor kernel support, connect to your device via ADB shell and execute:

adb shell
grep -i apparmor /proc/cmdline

If AppArmor is enabled, you might see output similar to apparmor=1 security=apparmor. Alternatively, check kernel security status:

adb shell
cat /sys/kernel/security/lsm

This should list apparmor among the supported LSMs.

Understanding AppArmor Profile Syntax

AppArmor profiles define what a confined application can and cannot do. They operate in two primary modes: enforce (blocking access) and complain (logging access violations without blocking). Key elements include:

• Profile Header: Defines the application executable and its mode. Example: profile /data/app/com.example.fileviewer-XYZ/base.apk { ... } (for an app launched directly, or more commonly profile { ... } for the main process).
• File Access Rules: Specify read (r), write (w), execute (x), append (a), link (k), memory map (m) permissions for files and directories.
• Capability Rules: Control access to specific kernel capabilities (e.g., capability net_raw).
• Network Rules: Define permissible network operations (e.g., network inet stream).
• Resource Rules: Restrict system resources like memory or CPU.
• Inheritance: Child processes inherit the parent’s profile by default, but can be switched using ix (inherit and execute) or px (pivot and execute).

Paths are often relative or use globbing (** for zero or more directories, * for zero or more characters).

Phase 1: Identifying Target Application Behavior

The first step in crafting an effective profile is understanding what resources your target Android app genuinely needs. For this tutorial, let’s consider a hypothetical