A Systematic Security Evaluation of Androids Multi-User Framework

Like many desktop operating systems in the 1990s, Android is now in the process of including support for multi-user scenarios. Because these scenarios introduce new threats to the system, we should have an understanding of how well the system design addresses them. Since the security implications of multi-user support are truly pervasive, we developed a systematic approach to studying the system and identifying problems. Unlike other approaches that focus on specific attacks or threat models, ours systematically identifies critical places where access controls are not present or do not properly identify the subject and object of a decision. Finding these places gives us insight into hypothetical attacks that could result, and allows us to design specific experiments to test our hypothesis. Following an overview of the new features and their implementation, we describe our methodology, present a partial list of our most interesting hypotheses, and describe the experiments we used to test them. Our findings indicate that the current system only partially addresses the new threats, leaving the door open to a number of significant vulnerabilities and privacy issues. Our findings span a spectrum of root causes, from simple oversights, all the way to major system design problems. We conclude that there is still a long way to go before the system can be used in anything more than the most casual of sharing environments.

💡 Research Summary

The paper conducts a systematic security assessment of Android’s multi‑user framework, which was introduced starting with Android 4.2 to allow several distinct user profiles on a single device. Recognizing that multi‑user support brings new attack surfaces, the authors develop a methodology that goes beyond isolated exploit demonstrations and instead identifies every location in the code where access‑control decisions are made without a clear definition of the subject (the user or app) and the object (the resource). Their approach combines static analysis of permission mappings with dynamic tracing of system calls to build a “subject‑object” matrix. By automatically flagging entries where the matrix is incomplete, they generate hypotheses about possible attacks, then validate those hypotheses on real devices.

The analysis reveals several classes of flaws. First, many system services use hard‑coded absolute file paths (e.g., “/data/user/0/settings.db”) without checking the calling user’s ID, allowing a malicious app in one profile to read or modify another profile’s private files. Second, ContentProviders and BroadcastReceivers often omit explicit user verification, so an app can issue cross‑profile queries or intercept broadcasts to gain elevated privileges. Third, the PackageManager fails to propagate permission information per‑user when an app is installed or removed, leaving the app’s permissions effectively shared across profiles. Fourth, shared external storage and the MediaStore database are not partitioned by user; files such as photos, audio, and documents are globally visible, creating privacy leaks.

From these observations the authors distill three root causes: (1) “subject‑object identification omission,” where the system does not consistently tag resources with the owning user; (2) “permission propagation gaps,” where user‑specific rights are not correctly inherited or revoked; and (3) “over‑exposed shared resources,” where common storage is not isolated. They construct seven concrete attack scenarios—ranging from unauthorized reading of another user’s contacts database to modifying system settings and escalating privileges without root—and successfully demonstrate each on unmodified Android builds.

The paper concludes that the current multi‑user implementation only partially mitigates the new threats. While basic UID isolation works for many cases, the identified design oversights enable significant vulnerabilities that could be exploited in everyday sharing situations, let alone in enterprise or educational environments where stronger guarantees are required. The authors recommend architectural changes: enforce user‑ID checks in every file‑system access, embed user identifiers in ContentProvider URIs, redesign the PackageManager to maintain per‑user permission tables, and partition external storage with per‑user namespaces. They also advocate for continuous automated security testing of multi‑user code paths as part of the Android development lifecycle. In sum, Android’s multi‑user framework is still far from being secure enough for anything beyond casual device sharing.