Overview

OpenHarmony's AccessToken model defines privilege levels, permission types, declarations, ACLs, user consent, and possible revocation, but the paper reports that selected alternate paths did not enforce the same boundary. Third-party apps could infer another app's activity from UID network statistics, obtain a protected serial through a system file, read or write DataAbility data despite declared permissions, receive sensitive Common Event payloads, or hijack a sensitive action through an implicit Want. The core lesson is system-wide enforcement: enumerate every route to a state, not just the named API. These findings concern tested surfaces and do not show that the entire AccessToken framework is ineffective.

Learning outcomes

OpenHarmony documents a clear permission contract, but selected interfaces did not enforce the same boundary in the reported cases.
A protected API cannot secure a state when an equivalent file, event, statistic, or component path exposes it.
Effective authorization must cover every route to a state, including read/write ownership and the lifetime of grants.

Keywords

OpenHarmonyAccessTokenpermissionsDataAbilityCommon EventsACL

The Side Doors Around a Permission Model

OpenHarmony's AccessToken architecture is the subject of this chapter, but the important question is larger than its permission names: does the same boundary hold across every interface that can expose or change a protected state? The answer matters because a reader evaluating OpenHarmony should be able to distinguish a documented policy from effective enforcement. The study's access-control and inter-process-communication cases show how an operating system can have an explicit privilege model while still leaving side doors through statistics, files, events, data-sharing components, or action routing.

The documented contract

A permission model begins as a statement about authority. OpenHarmony assigns applications an Ability Privilege Level, or APL, of normal, system_basic, or system_core; normal is the default. It also distinguishes system_grant permissions from user_grant permissions. Applications are expected to declare the permissions they need in their configuration, and the documentation says that an undeclared permission cannot be obtained. When a normal application needs a system_basic or system_core permission, it must declare the permission in an Access Control List as well.

The arrangement has a useful division of responsibility. The application declares its need. The platform evaluates whether that need is compatible with the application's privilege level. The user may then authorize a user_grant capability when the protected operation concerns private information or a system ability. Before an app calls such an API, the system checks the current grant status and can display a consent dialog. The documentation also warns that a user can later revoke the grant in Settings, so an earlier success cannot be treated as a permanent fact.

That last point is more than a detail about user experience. It defines the lifetime of authority. An application cannot safely assume that a capability granted yesterday remains valid today; it must check when the protected operation is about to occur and handle denial. For pre-installed applications, the platform provides a separate pre-authorization path in an installation permission file. That mechanism is explicitly limited to pre-installed apps, and a userCancellable setting determines whether the user may revoke the pre-authorization. The platform is therefore describing several different authority transitions: declaration, privilege validation, user consent, possible revocation, and, for a restricted class of apps, pre-authorization.

The contract is clear enough to create an expectation. If an ordinary app asks for a sensitive capability, the relevant permission and the current grant should govern whether the operation succeeds. If an elevated permission is needed, the ACL should constrain who can receive it. If user consent is required, the consent state should be checked at the time of use. A security evaluation can then ask whether those rules are applied consistently, rather than treating every unexpected result as mysterious.

But the contract is not the same as a single gate. A mobile operating system exposes information through system APIs, event subscriptions, shared data components, kernel-facing files, and inter-component actions. Each of those paths may be maintained by a different subsystem. If one path checks AccessToken state and another assumes that the caller is harmless, the second path expands the effective authority of an app without changing the official permission table.

Published by DeepMox

FAQ

What does OpenHarmony's AccessToken model control?

OpenHarmony's AccessToken model defines application privilege levels, permission declarations and grants, ACL requirements for elevated permissions, and user authorization for user_grant capabilities.

How can a protected identifier remain exposed in OpenHarmony?

A protected API can be bypassed when an alternate system-file view exposes an equivalent value; the paper reports this for the device serial.

Why must permission reviews include events and shared data?

Because a Common Event or DataAbility can disclose or modify protected state without following the permission rule enforced by the primary API, as reported in the tested cases.

Previous12 minWhat Transfers Between OpenHarmony and Android?

Next12 minOpenHarmony's High-Fidelity Attack Surfaces

OpenHarmony AccessToken Permission Gaps

The Side Doors Around a Permission Model

The documented contract

FAQ