<h2>Introduction</h2><p>SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) security mechanism implemented in the Linux kernel. On Android devices, it plays a critical role in enforcing granular security policies, isolating apps, and protecting system resources from malicious or misbehaving processes. While powerful, SELinux can sometimes be overly restrictive for advanced users or developers creating custom modifications. Traditionally, patching SELinux required modifying the system partition, a method that is cumbersome, breaks OTA updates, and is often incompatible with modern Android security architectures. This is where Magisk modules shine, offering a systemless approach to dynamically patch SELinux policies, enabling system-wide customization without compromising system integrity.</p><h2>Understanding SELinux on Android</h2><p>Android utilizes SELinux extensively. Every process, file, and IPC mechanism is labeled with an SELinux context (e.g., <code>untrusted_app</code>, <code>system_server</code>, <code>/data/media_rw</code>). The kernel then uses a policy to determine if an operation (e.g., <code>read</code>, <code>write</code>, <code>execute</code>) by a source context on a target context is permitted. Policies are compiled into a binary format and loaded during device boot.</p><h3>SELinux Modes</h3><ul><li><strong>Enforcing:</strong> All unauthorized actions are blocked and logged. This is the default and most secure mode.</li><li><strong>Permissive:</strong> Unauthorized actions are logged but not blocked. Useful for debugging policy violations.</li></ul><p>The policy itself is composed of Type Enforcement (TE) files written in a specific language, then compiled into a Common Intermediate Language (CIL) format, and finally into a binary <code>sepolicy</code> file. This binary policy is part of the <code>boot.img</code> or loaded from the <code>vendor</code> partition depending on the Android version and device.</p><h2>Why Patch SELinux with Magisk?</h2><p>Magisk’s strength lies in its systemless interface, which allows modifications to be made without touching the <code>/system</code> partition. For SELinux, this means:</p><ul><li><strong>Preservation of OTAs:</strong> System updates can often be applied without losing root or custom modifications.</li><li><strong>Flexibility:</strong> Policies can be added, modified, or removed easily by enabling/disabling a module.</li><li><strong>Safety:</strong> If a policy causes issues, the device can often be booted without Magisk, or the module can be removed via recovery.</li></ul><p>Magisk provides its own SELinux patching capabilities, primarily through the <code>magisk_selinux_patch_policy</code> function exposed in the module’s <code>customize.sh</code> or <code>post-fs-data.sh</code> scripts. This allows injecting new rules or modifying existing ones into the currently loaded policy in memory.</p><h2>Prerequisites</h2><p>Before diving into advanced patching, ensure you have:</p><ul><li>A rooted Android device with Magisk installed.</li><li>Basic familiarity with Magisk module development (using the module template).</li><li><code>adb</code> and <code>fastboot</code> installed on your computer.</li><li>The Android NDK (for <code>secilc</code> and other SELinux tools).</li><li>A text editor and a command-line environment.</li></ul><h2>Method 1: Using <code>sepolicy-inject</code> for Simpler Cases</h2><p><code>sepolicy-inject</code> is a powerful utility often bundled with custom ROMs or available as a standalone binary. It allows injecting specific allow rules, type definitions, or attribute assignments directly into the live SELinux policy. It simplifies common patching tasks.</p><h3>Example: Granting a Custom Service Permissions</h3><p>Let’s say you have a custom daemon or service running as <code>my_custom_daemon</code> that needs to read a file <code>/data/misc/my_config.txt</code> which is labeled <code>app_data_file</code>. Without policy changes, this would likely be denied.</p><h4>Steps:</h4><ol><li><strong>Identify the denial:</strong> Start your custom service and check <code>dmesg</code> or <code>logcat -b events -s auditd</code> for <code>avc: denied</code> messages. You’ll see something like <code>{ read } for pid=<PID> comm="my_custom_daemon" name="my_config.txt" dev="dm-0" ino=<INO> scontext=u:r:my_custom_daemon:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0</code>. This tells you <code>my_custom_daemon</code> tried to <code>read</code> <code>app_data_file</code>.</li><li><strong>Construct the rule:</strong> The simplest allow rule would be <code>allow my_custom_daemon app_data_file:file { read };</code>.</li><li><strong>Integrate into Magisk module:</strong> Place <code>sepolicy-inject</code> (ensure it’s compatible with your device’s architecture, e.g., <code>arm64</code>) in your module’s <code>system/bin</code> directory and execute it in <code>post-fs-data.sh</code>.</li></ol><pre><code># module.prop entry (example)run_scripts=post-fs-data.sh</code></pre><pre><code># post-fs-data.sh exampleMODULE_DIR=${0%/*}chmod 0755 $MODULE_DIR/system/bin/sepolicy-inject$MODULE_DIR/system/bin/sepolicy-inject -s my_custom_daemon -t app_data_file -c file -p read -P /sys/fs/selinux/policyexit 0</code></pre><p>The <code>-P /sys/fs/selinux/policy</code> argument tells <code>sepolicy-inject</code> to target the active policy. This command adds the specific permission to the live policy.</p><h2>Method 2: Manual CIL Patching for Complex Scenarios</h2><p>When <code>sepolicy-inject</code> isn’t flexible enough (e.g., creating new types, attributes, or more complex conditional rules), you need to work directly with CIL. Magisk provides a convenient way to apply CIL patches.</p><h3>Understanding CIL</h3><p>CIL (Common Intermediate Language) is a human-readable representation of SELinux policy. It’s what <code>secilc</code> compiles into the binary <code>sepolicy</code> file. Knowing CIL allows you to craft precise policy additions.</p><h4>Steps:</h4><ol><li><strong>Extract the current policy:</strong><pre><code>adb pull /sys/fs/selinux/policy ./policy.30</code></pre></li><li><strong>Convert to CIL:</strong> Use <code>secilc</code> from the Android NDK (or a precompiled binary) to convert the binary policy to CIL.<pre><code>path/to/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/secilc -P policy.30 -o policy.cil -m </code></pre><p>The <code>-m</code> flag makes the output more readable by converting TE rules to CIL macros.</p></li><li><strong>Analyze and Write Custom CIL Rules:</strong> Examine <code>policy.cil</code> to understand existing types and rules. Then, create your custom CIL file (e.g., <code>my_custom_policy.cil</code>) within your Magisk module’s directory (e.g., <code>sepolicy.d/</code>).</li></ol><p><strong>Example CIL for a new domain and file type:</strong></p><pre><code>(type my_new_domain)(typeattribute my_new_domain_attribute)(type my_new_file_type)(typeattribute my_new_file_attribute)(allow my_new_domain my_new_file_type (file (read write open))) # Grant access to new file type(allow my_new_domain system_file (file (read execute))) # Allow execution of system binaries(type_transition init my_new_domain_exec my_new_domain) # Transition from init to new domain</code></pre><ol start="4"><li><strong>Patching the Policy with Magisk:</strong> Magisk simplifies CIL injection. Place your custom CIL files (e.g., <code>my_custom_policy.cil</code>) inside a <code>sepolicy.d/</code> directory within your module’s root. Magisk will automatically detect and apply these. For more control, you can call <code>magisk_selinux_patch_policy</code> in your <code>post-fs-data.sh</code> script.</li></ol><pre><code># In post-fs-data.shMAGISK_LOGFILE=/dev/nullLOGFILE=$MAGISK_LOGFILEMAGISK_DEBUG=1 # Enable for detailed logging# Check if magisk_selinux_patch_policy exists (Magisk v20.4+ provides it)if [ -f $MAGISK_PATH/magisk_selinux_patch_policy ]; then # Apply CIL patches from sepolicy.d/ # Magisk will automatically look for .cil files in sepolicy.d/ # and merge them if the directory exists. # If you want to apply a specific CIL file programmatically: # $MAGISK_PATH/magisk_selinux_patch_policy –policy $MAGISK_TMP/policy –apply $MODULE_DIR/sepolicy.d/my_custom_policy.cil # For a simple sepolicy.d folder, Magisk handles it implicitly. ui_print "- SELinux policy patches will be applied."else ui_print "! Magisk SELinux patching not available or Magisk version too old."fi</code></pre><p>For Magisk to automatically apply CIL files, simply place them in the <code>sepolicy.d/</code> folder at the root of your module. Magisk scans this directory and merges all <code>.cil</code> files found there into the live policy during boot.</p><h2>Developing the Magisk Module</h2><p>Your Magisk module structure will typically look like this:</p><pre><code>MySELinuxModule/├── module.prop├── customize.sh├── post-fs-data.sh├── service.sh├── system/│ └── bin/│ └── sepolicy-inject (if used)└── sepolicy.d/ └── my_custom_policy.cil (if using CIL patches)</code></pre><ul><li><strong><code>module.prop</code>:</strong> Defines metadata for your module.</li><li><strong><code>customize.sh</code>:</strong> Executed during module installation. Can perform pre-patch checks or setup.</li><li><strong><code>post-fs-data.sh</code>:</strong> Executed after <code>/data</code> is mounted but before services start. Ideal for applying SELinux patches.</li><li><strong><code>service.sh</code>:</strong> Executed once services have started. Use if your policy requires interaction with running services.</li></ul><h3>Debugging SELinux Changes</h3><ul><li><strong><code>dmesg</code>:</strong> Check for <code>avc: denied</code> messages.</li><li><strong><code>audit_log</code>:</strong> On some devices, <code>cat /sys/fs/selinux/audit_log</code> provides detailed audit records.</li><li><strong>Permissive mode:</strong> Temporarily switch to permissive mode (<code>setenforce 0</code>) to see what would be denied without blocking it. <strong>Do not use this in production!</strong></li></ul><h2>Best Practices and Warnings</h2><ul><li><strong>Granularity:</strong> Always aim for the most granular permissions possible. Avoid overly broad <code>allow</code> rules (e.g., <code>allow * * *</code>).</li><li><strong>Testing:</strong> Thoroughly test your policy changes. A broken SELinux policy can brick your device or leave it in a boot loop.</li><li><strong>Security Implications:</strong> Understand that patching SELinux weakens the device’s security model. Only grant permissions that are strictly necessary.</li><li><strong>Device Compatibility:</strong> SELinux policies can vary significantly between Android versions and device manufacturers. Always verify the existing policy before applying changes.</li></ul><h2>Conclusion</h2><p>Advanced SELinux policy patching with Magisk modules provides an unparalleled level of system customization and control for expert users and developers. By understanding the underlying SELinux architecture and leveraging Magisk’s systemless capabilities, you can tailor your Android device’s security profile to precisely meet your needs, all while maintaining the integrity and updateability of your system.</p>