Android Multi-Level System Permission Management Approach

With the expansion of the market share occupied by the Android platform, security issues (especially application security) have become attention focus of researchers. In fact, the existing methods lack the capabilities to manage application permissions without root privilege. This study proposes a dynamic management mechanism of Android application permissions based on security policies. The paper first describes the permissions by security policies, then implementes permission checking code and request evaluation algorithm in Android framework layer. Experimental results indicate that the presented approach succeeds in permission management of Android applications, and its system overhead is low, which makes it an effective method for Android permission management.

💡 Research Summary

The paper addresses two major security shortcomings of the Android platform: (1) the coarse‑grained discretionary access control (DAC) used in the Linux kernel layer, and (2) the lack of runtime control over application permissions in the framework layer.
To strengthen the kernel layer, the authors first identify the 15 Linux users that act as process UIDs in Android 5.1. They construct a “Linux user permission relationship tree” where an edge U1 < p U2 denotes that the permissions of U1 are a subset of those of U2. Three security constraints are derived from this relation: (i) a lower‑privilege user may not read or execute files owned by a higher‑privilege user, (ii) a higher‑privilege user may not write files owned by a lower‑privilege user, and (iii) a lower‑privilege process may not transition to a higher‑privilege domain.
Because Android’s SELinux implementation only uses a single sensitivity level (s0), the authors propose an algorithm that maps the tree into a Multi‑Level Security (MLS) model. Starting from the root, they assign decreasing sensitivity levels (s2, s1, s0) down the tree and generate category sets for leaf nodes based on user names. The resulting MLS labels are inserted into SELinux policy files (service_contexts, file_contexts, property_contexts), thereby enforcing the derived constraints without requiring kernel modifications or root privileges.
For the framework layer, the paper introduces a dynamic permission management architecture composed of a Policy Decision Point (PDP), a Policy Information Point (PIP) that stores XML‑based policy files, and a Policy Enforcement Point (PEP) that intercepts permission requests. The policy language supports signed white‑lists, black‑lists, and an “allow‑all” tag, allowing fine‑grained per‑package rules. When an app requests a permission, the PEP forwards a request tuple {package name, signature, permission} to the PDP. The PDP opens the policy file, locates the signature block, then performs binary searches for the package and the specific permission. If the permission is found in a white‑list (and white‑mode is true) the request is granted; if it is absent in a black‑list (white‑mode false) it is also granted; otherwise it is denied. The algorithm runs in O(m·n) time, where n is the number of installed apps and m is the average number of permissions per app.
Implementation was carried out on two platforms: a UT4412 development board running Android 4.4 and a Nexus 5 device running Android 5.1. The kernel‑level MLS rules were added to SELinux’s constraint configuration, and eight critical permission check points (contacts, SMS, microphone, camera, location, etc.) were instrumented in the framework code.
Experimental evaluation consists of three parts. First, five popular rooting tools (KingRoot, 360 One‑Click Root, Baidu One‑Click ROOT, Root Wizard, and “刷机大师”) were tested. KingRoot and “刷机大师” could install their management APKs because they were whitelisted, but they could not execute privileged operations such as accessing protected system files. The other three tools failed to install their APKs, effectively preventing privilege escalation. Second, 50 applications (30 benign, 20 malicious) were subjected to dynamic permission revocation. The system blocked unauthorized permission use with 98 % accuracy; the only miss was Baidu Maps, which continued to obtain location via cellular and Wi‑Fi after GPS permission was revoked. Revoking those additional network permissions achieved full blocking. Third, performance measurements showed that the inserted check points added an average latency of only about 140 µs per call, negligible compared with the baseline operation times (≥1.7 ms).
In summary, the paper makes three key contributions: (1) a practical method to convert Android’s DAC‑based user model into an MLS‑based multi‑level security scheme, (2) a policy‑driven dynamic permission evaluation framework integrated into the Android runtime without requiring root access, and (3) empirical evidence that the combined approach effectively thwarts root‑based attacks and over‑privileged app behavior while imposing minimal runtime overhead. Remaining challenges include protecting the integrity of the policy files themselves, automating MLS level management, and handling apps that employ alternative channels to achieve the same functionality after a permission is revoked.