Otukan hardens the privileged components of an Android device by mapping what each preinstalled app and system service is allowed to do, removing privilege it does not need, and checking that map again in every authorised build and security update. The work covers apps signed with your platform key, apps in the privileged directories of your system image, vendor services and the interfaces they expose to other code. It runs inside your build and signing process, per model and chipset, for Android-based devices whose system image you or your ODM build. It is part of a device programme, not a scan of an arbitrary image.
Privilege map
A privileged component is any code in the system image that can do more than a store app. On Android, that power comes from a small number of sources, and Otukan records each one per component.
Where privilege comes from
- Signing identity. Apps signed with the platform key can be granted signature permissions. Apps that also declare the shared system user ID run with the identity of the system itself.
- Privileged directories. Apps placed in a priv-app directory can request privileged permissions, and the build must list each grant in an allowlist file. Otukan checks that every entry has a reason.
- Default grants. Runtime permissions can be granted in advance to preinstalled apps, without the user seeing a prompt.
- Access control domain. Each process runs in an SELinux domain whose policy decides which files, devices and services it may touch.
Interfaces and attack boundaries
Privilege becomes risk where other code can reach it. Otukan lists the exported activities, services, broadcast receivers and content providers of each privileged app, and the system service calls a vendor service offers, together with the permission that guards each entry point. An interface that a store app can call without a matching permission is an attack boundary, and it goes on the map with its owner.
| Component | Privilege source | Reachable from | Guarded by |
|---|---|---|---|
| Platform-signed settings app | Platform key, shared system user ID | Other apps through exported activities | Signature permission per activity |
| Preinstalled update client | Priv-app directory, allowlisted privileged permissions | System and apps through a bound service | Caller signature check |
| Vendor hardware service | Vendor partition, own SELinux domain | System services through its interface | SELinux policy and interface permissions |
The table shows the shape of the map, not a finding. Your map lists the real components of each model.
Control scope
Not every finding calls for the same action. Otukan agrees with you, for each finding, which of three routes applies, so ownership is clear before work starts.
- Monitoring. A privilege that the component legitimately needs stays in place and is watched. Otukan records the justification and reports any change to it in later builds.
- Hardening in your build. Where you own the configuration, Otukan narrows it: permissions leave the allowlist, an exported interface closes or gains a signature permission, a component moves from system identity to its own, an SELinux rule becomes stricter. Each change is tested on the physical device so that functions users depend on keep working.
- Supplier remediation. Where the flaw sits in code a supplier owns, the fix belongs to that supplier. Otukan contains the exposure in your image in the meantime, tracks the finding by component version, and verifies the corrected release when it arrives.
This split makes ownership explicit from the first finding. A preinstalled component that no one owns is itself a finding, and the programme names an owner before the build ships.
Validation through builds and updates
A privilege map is only useful while it matches the image on the device. Otukan keeps it current through the life of the model.
- Authorised builds. Every candidate build is compared with the approved map. A new privileged app, a new allowlist entry or a newly exported interface is raised for review before release.
- Security updates. Platform and vendor security updates change system components. Otukan checks that fixes arrived as expected and that no privilege widened on the way.
- Supplier updates. A new version of a supplier component is checked against its predecessor, so a changed permission request or interface is seen before it reaches devices.
- Evidence for owners. Each release carries a record of what changed, who approved it and which tests ran on which device.
What a sensitive public-sector programme should ask about privileged components is covered on government mobile device security. Whether a device is running the build you approved is covered on device integrity signals. Firmware integrity is covered on Android firmware integrity. The wider device architecture is covered on Android device security architecture. For the full device programme, see mobile device security.