Android SELinux Internals Part III - Kernel-Level SELinux By...

[carlospolop]

🤖 Automated Content Update

This PR was automatically generated by the HackTricks News Bot based on a technical blog post.

📝 Source Information

• Blog URL: https://8ksec.io/android-selinux-internals-part-iii
• Blog Title: Android SELinux Internals Part III - Kernel-Level SELinux Bypass and Real-World Exploit Chains
• Suggested Section: Mobile Pentesting > Android Applications Pentesting > Android Kernel Exploitation and SELinux Bypasses, with a cross-link from Binary Exploitation > Linux kernel exploitation

🎯 Content Summary

Scope and threat model

Android SELinux Internals Part III assumes that an attacker has already obtained an arbitrary kernel read/write primitive, for example through a use-after-free, out-of-bounds write, or another kernel memory-corruption bug. Kernel read/write alone does not change the process UID, credentials, or SELinux domain, so SELinux remains the main obstacle to turning the primitive into full device compromise. The post explains six kernel-level SELinux byp...

🔧 Technical Details

Global SELinux-state corruption: An attacker who already has arbitrary kernel write can locate the legacy selinux_enforcing integer or the newer selinux_state.enforcing field through /proc/kallsyms, a separate kernel information leak, build-specific offsets, or KASLR-slide calculation. Writing zero changes the entire device to permissive mode while AVC denials continue to be logged.

Domain-scoped permissive mode: Read the process context from /proc/self/attr/current, resolve the corresponding SELinux type ID through the policy database or SETools, locate selinux_state->policy->policydb->permissive_map, and set the type's ebitmap bit using ebitmap_set_bit(&pdb->permissive_map, target_type_id, 1). This makes only processes in the selected domain permissive.

AVC cache poisoning: Locate the AVC hash table, calculate avc_h...

🤖 Agent Actions

Plan:

1. Map the Android, SELinux, and kernel-exploitation documentation and inspect at least five candidate pages.
2. Fetch the supplied article and its primary research; compare techniques against existing coverage.
3. Select one canonical location, implement a concise cited update, and add only necessary cross-links.
4. Validate references, paths, formatting, and the final Git diff.
   Repository mapping is complete. Next I’m checking the Android landing page, the Linux-kernel exploitation index and representative kernel/SELinux pages to avoid duplicating existing material and to match local style.
   The existing corpus covers Android kernel primitives and GPU/SMMU takeovers, but not post–kernel-R/W SELinux data-target selection. I’m now verifying the article against the credited primary research and upstream kernel structures before drafting one dedicated binary-exploitation page.
   Source verification shows the primary research supports six post-R/W targets, while the Black Hat work supports page-level cross-cache grooming and permission-map corruption—not the article’s more specific claim that an AVC-node spray itself was demonstrated. I’ll preserve that distinction and omit unverified pKVM/GKI generalizations.
   I’m implementing the verified material as a single canonical kernel-exploitation page, then adding discovery links from Android pentesting, the GPU/SMMU page, and the book summary. The page will explicitly correct the article’s permission-map simplification: zeroed mappings only become permissive when allow_unknown is enabled, and stale AVC denials may still need invalidation/patching.
   The implementation is in place. I’m now doing a technical review of constants and version caveats, checking every internal path/reference, then running repository-level formatting/build validation.
   One remaining check is the kernel-side constant name/value for allow_unknown; I’m verifying it against upstream source so the pseudocode does not accidentally use a userspace-only libsepol symbol.
   Technical review is complete: the permission-map pseudocode now writes the kernel’s boolean allow_unknown field rather than a libsepol-style constant. Final validation will check source availability, code fences, reference numbering, internal links, and the clean diff.
   Implemented the HackTricks update.

Changes

• Added src/binary-exploitation/linux-kernel-exploitation/android-kernel-selinux-bypass.md
  • Six kernel-level SELinux corruption targets
  • AVC poisoning
  • Cross-cache targeting
  • GPU/SMMU write pivots
  • Exploit-chain ordering and version-specific caveats
  • Numbered primary-source references
• Corrected the permission-map technique: zeroing num_perms alone does not grant access; allow_unknown and preserved permission slots are required.
• Added cross-links from:
  • Android Applications Pentesting
  • Adreno GPU/SMMU exploitation
  • SUMMARY.md

Validation

• Internal references resolve.
• Citations and code fences validated.
• External references return HTTP 200.
• git diff --check passes.
• mdbook was unavailable in the environment, so a full build could not be run.

---

This PR was automatically created by the HackTricks Feed Bot. Please review the changes carefully before merging.

[carlospolop]

🔗 Additional Context

Original Blog Post: https://8ksec.io/android-selinux-internals-part-iii

Content Categories: Based on the analysis, this content was categorized under "Mobile Pentesting > Android Applications Pentesting > Android Kernel Exploitation and SELinux Bypasses, with a cross-link from Binary Exploitation > Linux kernel exploitation".

Repository Maintenance:

• MD Files Formatting: 1032 files processed

Review Notes:

• This content was automatically processed and may require human review for accuracy
• Check that the placement within the repository structure is appropriate
• Verify that all technical details are correct and up-to-date
• All .md files have been checked for proper formatting (headers, includes, etc.)

Bot Version: HackTricks News Bot v1.0