security-selinux-expert

name: security-selinux-expert layer: L2 path_scope: system/sepolicy/, vendor//sepolicy/, device//sepolicy/, *.te, file_contexts, property_contexts, service_contexts version: 1.1.0 android_version_tested: Android 16 parent_skill: aosp-root-router

Path Scope

Trigger Conditions

Load this skill when the task involves:

• Any avc: denied log line — always routed here exclusively
• Adding a new vendor daemon or system service requiring SELinux domain
• Writing or modifying .te files
• audit2allow output interpretation
• neverallow rule violations in build
• CTS SELinux tests failing
• File labeling: restorecon, chcon, file_contexts
• Property access denials (property_contexts)
• Binder/HIDL service registration failures (service_contexts, hwservice_contexts)
• Security audit or policy review

Architecture Intelligence

SELinux Policy Layers (Android)

Compile-time merge:
  system/sepolicy/public/      ← Stable; exported to vendor
  system/sepolicy/private/     ← Internal; NOT exported
  system/sepolicy/vendor/      ← Generic vendor types
  vendor/*/sepolicy/           ← OEM additions
  device/*/sepolicy/           ← Device-specific additions
         │
         ▼
  Compiled into: system/sepolicy.cil  +  vendor/sepolicy.cil

avc: denied Anatomy

avc: denied { <permission> } for pid=<N> comm="<process>"
  path="<file>" dev="<device>" ino=<N>
  scontext=u:r:<source_domain>:s0
  tcontext=u:object_r:<target_type>:s0
  tclass=<object_class>

Key fields:
  permission    → what was attempted (read, write, open, ioctl, …)
  source_domain → the process's SELinux type (the subject)
  target_type   → the object's SELinux type (the resource)
  tclass        → the object class (file, dir, property_file, binder, …)

Resolution Workflow

1. Capture full avc: denied log
2. Identify source_domain → is it a platform or vendor domain?
3. Check if a broader allow rule already exists (policy may just be missing on device)
4. Draft minimum allow rule:
     allow <source_domain> <target_type>:<tclass> { <permission> };
5. Check against neverallow rules:
     grep -r "neverallow.*<source_domain>" system/sepolicy/
6. Place rule in correct file:
     - Platform domain → system/sepolicy/private/<domain>.te
     - Vendor domain   → vendor/<OEM>/sepolicy/<domain>.te
7. Label any new files in file_contexts
8. Build and verify: atest CtsSecurityHostTestCases

Neverallow Rules — Critical Boundaries

Treble Policy Split

• Public policy (system/sepolicy/public/) is versioned. Vendor policy extends it but cannot modify it.
• When adding a new type that vendor modules must reference, it must go in public/, not private/.
• vendor_domain attribute marks a type as vendor-owned — it cannot call non-VNDK system services directly.

File Contexts Syntax

# Pattern                           Label
/vendor/bin/my_daemon               u:object_r:my_daemon_exec:s0
/data/vendor/myapp(/.*)?            u:object_r:myapp_data_file:s0
/dev/my_device                      u:object_r:my_device_dev:s0

Property Contexts Syntax

# Prefix                            Label
vendor.myapp.                       u:object_r:vendor_myapp_prop:s0
ro.myapp.version                    u:object_r:vendor_myapp_prop:s0

Android 15 SELinux / Security Changes

Android 16 SELinux / Security Changes

IOCTL hardening audit workflow:

1. Identify all vendor IOCTLs in your kernel drivers
2. Check each IOCTL against the restricted list in system/sepolicy/
3. Classify: production-required vs. development-only vs. profiling-only
4. Ensure development/profiling IOCTLs are gated on userdebug/eng builds
5. Synchronize IOCTL allowlists with vendor HAL userspace components

Forbidden Actions

1. Forbidden: Using audit2allow output verbatim without reviewing each rule — audit2allow generates the widest possible allow rules; always narrow scope to minimum required permissions.
2. Forbidden: Adding allow rules to system/sepolicy/private/ for vendor domains — vendor domains must use vendor/<OEM>/sepolicy/ or system/sepolicy/vendor/.
3. Forbidden: Modifying SELinux policy in frameworks/ — all policy lives in system/sepolicy/ or vendor/device sepolicy paths.
4. Forbidden: Using permissive <domain> as a permanent fix — permissive mode disables enforcement for the entire domain and is only acceptable as a temporary debug aid.
5. Forbidden: Adding allow <source> <target>:file { open read write } without first checking neverallow constraints — always grep neverallow before writing new allow rules.
6. Forbidden: Placing vendor-domain .te files in system/sepolicy/private/ — the public/private split is a Treble ABI boundary.
7. Forbidden: Routing a resolved SELinux task back to the router without also checking if the underlying process code needs changes — coordinate with the relevant L2 skill for the daemon's code path.

Tool Calls

# Analyze avc: denied and draft allow rules (use with caution — review output)
audit2allow -i <logfile>

# Check if a type is already defined in platform policy
grep -r "^type <type_name>" system/sepolicy/

# Find all allow rules for a domain
grep -r "allow my_daemon" system/sepolicy/ vendor/*/sepolicy/

# Check neverallow constraints affecting a type
grep -r "neverallow.*my_daemon\|neverallow my_daemon" system/sepolicy/

# Find file_contexts label for a path
grep -r "/path/to/file" system/sepolicy/ vendor/*/sepolicy/ device/*/sepolicy/

# Verify sepolicy compiles (run from AOSP root)
m sepolicy_tests
m CtsSecurityHostTestCases

Handoff Rules

Emit [L2 SECURITY → HANDOFF] before transferring.

References

• references/selinux_policy_guide.md — Android SELinux policy authoring reference.
• system/sepolicy/README — upstream policy documentation.
• system/sepolicy/public/ — platform-stable type definitions.
• ANDROID_SW_OWNER_DEV_PLAN.md §5 — L2 skill design spec.