Threat-model an Android system

Before you start#

Required: Android’s Security Model, Verified Boot and Encryption, Rooting Methods, and Magisk and Systemless Root. Optional: SELinux Policy Lab for access-policy evidence. This chapter teaches structured analysis, not exploit development, concealment, or device modification. The configurations are archetypes; they are not universal descriptions of every Android product.

Learning goals#

Define assets, adversaries, trust boundaries and assumptions; draw a request/data flow; identify the trusted computing base (TCB); compare assurance deltas across four Android configurations without declaring a universal safety ranking; distinguish source-derived statements from device observations and unknowns; and make a reasoned stop/continue decision for an owner-authorized lab.

A small threat-modeling method

A threat model is a compact account of what needs protection, from whom, through which paths, and under which assumptions. It is not a list of every imaginable attack and not proof that no vulnerability exists. Use these steps:

1. Name assets. Examples: CE user files, account tokens, app-private data, verified OS integrity, signing/update keys, availability/recoverability, and secrets held by hardware-backed services.
2. Name adversaries and capability. Examples: someone holding a locked lost phone; a malicious ordinary app; an app that the owner has explicitly granted root; a person with physical access and an authorized unlocked bootloader; a compromised update/root manager. Specify what they can actually do. “Attacker” without capability is not a useful model.
3. Draw the path. Mark app/process, Binder service, kernel/DAC/SELinux, bootloader and storage-key boundaries as relevant. Show both control flow (who authorizes) and data flow (where the sensitive data moves).
4. List assumptions and evidence. Separate claims established by pinned source, observed on an exact build, documented by a vendor, and merely assumed. Missing evidence stays unknown.
5. Compare the delta. What trust anchor, privileged component, policy, or recovery path changed? Which controls remain? What is the residual risk for the chosen adversary?

Worked request and data-flow sketch

Consider an ordinary app asking a system service to read a protected setting. The framework permission is granted to that app. Android assigns apps UIDs for the kernel sandbox (AOSP Application Sandbox), while framework permissions authorize selected operations (AOSP permissions). A simplified path is:

app process (UID + SELinux domain)
   │ Binder transaction; caller identity accompanies request
   ▼
system service (checks caller UID / Android permission / service policy)
   │ service opens backing file with its own credentials
   ▼
Linux kernel: DAC + SELinux policy + other kernel checks
   │
   ▼
storage: file availability may depend on FBE key state

Separate boot path:
device trust anchor → bootloader / AVB policy → boot images and verified partitions

A permission grant only matters where a framework/API checks it; it does not make the app UID 0. The service may be allowed to read a file the app cannot open directly. If the backing data is CE-encrypted and its key is unavailable, root UID alone does not produce that key; AOSP distinguishes CE availability after user unlock from DE availability during Direct Boot in its FBE documentation. The boot chain answers which code is accepted, not whether a particular API caller may read a file (Verified Boot). These are independent dimensions.

Four configurations: assurance deltas, not rankings

The table describes common conceptual differences. Actual policies, partitions, hardware roots, build flags, and vendor integration vary. No physical device was tested for this chapter.

Do not order these as “configuration A is always safer than B.” The answer changes with asset/adversary. A debug image may be the best choice for reproducible source learning and a poor choice for sensitive personal data. An unlocked non-root image changes boot trust without granting every app root. Root may help an owner inspect a lab while making compromise of the requester/manager more consequential.

TCB inventory and evidence discipline

For each claim, tag it S (pinned source), O (observed on exact build), D (device/vendor documentation), or U (unknown). Example: “AOSP Android 14 adbd checks ro.debuggable in the root request branch” is S for the pinned AOSP revision; “this phone’s bootloader is locked” requires O/D evidence; “this manager revokes a running child immediately” is U unless exact source or a controlled test proves it.

Common TCB components to inventory:

The TCB can expand or change after root modifications. A statement about stock system/sepolicy is evidence about that source tree, not automatically about a rooted vendor device. A global getenforce result says mode, not the effective domain or every rule. Inspect process context and actual policy where available, and mark missing facts unknown.

Adversarial worksheet

Complete this table for one configuration and one adversary. Keep it specific; “root is dangerous” is not an answer.

Review case and reasoned answer

Case: An owner has a disposable userdebug emulator. adb root succeeds. id reports UID 0, getenforce reports Enforcing, and id -Z reports a process context. The owner concludes that SELinux is unchanged, the OS has production assurance, and any denied read must be a DAC problem.

Reasoned answer: Only the first two observations are established (assuming the commands targeted the intended emulator): this shell has UID 0, and the global SELinux mode reports enforcing. The context gives another distinct process property. None proves the loaded policy is byte-for-byte stock, that this root domain has narrow permissions, or that build/boot assurance matches a retail production device. A refusal could be DAC, SELinux, a framework/service check, or another kernel condition; an AVC can support SELinux attribution, but absent logs do not clear SELinux. Record build fingerprint/type and inspect exact policy/context; do not disable SELinux. For sensitive-data threat modeling, the debug build and host pipeline are additional trust assumptions. This case has no universal risk ranking; the conclusion depends on assets and adversary.

Practice#

Pick one asset and one adversary from the table. Fill the worksheet for (a) stock locked, (b) unlocked but no root manager, (c) development root image, and (d) modified kernel/root manager. Write one sentence per configuration stating assurance gained/lost for that specific threat. Use citations for source claims and unknown for unobserved vendor facts. No device change is part of the exercise.

Knowledge check#

1. Does bootloader unlock imply UID 0 for apps?
2. Does getenforce=Enforcing prove an effective stock policy for a modified root build?
3. Why can an unlocked non-root device have lower boot assurance than a locked stock device?
4. Name three root-configuration TCB elements beyond the requesting app.
5. What is the right response when the device-specific recovery/rollback state is unknown before a proposed hardware change?

Answers#

1. No. Unlock changes boot acceptance policy; root is runtime privilege/authorization.
2. No. It reports global mode, not effective policy provenance, domain, capabilities or every permission.
3. The bootloader may accept software outside the manufacturer’s normal verified chain even though no app has root.
4. Examples: modified boot component/kernel, daemon, manager, policy store/key, SELinux policy, update/recovery tooling.
5. Stop before irreversible modification; obtain exact vendor instructions and a verified recovery plan. This chapter does not authorize a generic flash/relock procedure.

Checkpoint#

Submit four configuration rows, one adversary-specific data-flow diagram, a TCB inventory with S/O/D/U evidence tags, and a decision with residual risk. Ready if the comparison is conditional on assets/adversary and unknowns remain explicit; revise if “locked/rooted/green” is used as a complete verdict; not yet evidenced if device state is asserted without observation or exact documentation. Remediation: redo the worksheet using one narrower adversary and cite the evidence for each gate.

Sources#

• AOSP, Application Sandbox, SELinux concepts, Verified Boot, device state, and FBE, current documentation accessed 2026-10-26.
• AOSP system/sepolicy at android-14.0.0_r1, source policy, not a guarantee about OEM compiled or modified policy.
• AOSP adbd main.cpp at android-14.0.0_r1, pinned source for the development-build example.
• Magisk v28.1 pinned source commit 218327f92b572c183718e0fe722c2babf293535f, third-party implementation example; not generalized to other versions.
• Device-specific boot/recovery behavior is deliberately not generalized. No Android build, device, OTA, or recovery workflow was tested for this lesson.

Next: OTA updates and rollback analysis