Lecture 20: Mobile Phone Security

What this lecture covers

This lecture treats Android as a case study in a system designed with security in mind from the start, unlike Unix or web browsers where security was added later. It walks through how an Android application is structured into components, how permissions ("labels") are declared and enforced, and why some resources are checked by a central reference monitor while others are enforced directly through Linux user and group IDs.

It follows the Android security paper and sits alongside the course's earlier Unix and browser security material, reusing ideas like UID-based isolation from an earlier lab. After watching, you should be able to describe Android's four component types, explain how the reference monitor mediates intents, and identify concrete weaknesses in how permission labels are defined and checked.

Key ideas

• Reference monitor: a central Android process that mediates intents (inter-app messages) between applications and checks permission labels before delivering them.
• Components: every Android app is built from activities (UI), services (background work), content providers (SQL-like data storage), and broadcast receivers (system-wide messages), rather than one monolithic program.
• Manifest: an XML file listing an app's requested permissions and the permissions required to interact with its components, letting the framework enforce a security policy separately from the app's code.
• Labels as strings: permissions are arbitrary, developer-defined strings (like dial perm), not centrally allocated identifiers, which makes them flexible but vulnerable to naming collisions.
• UID/GID enforcement: performance-sensitive resources like network sockets, SD card access, and hardware devices are checked directly by the Linux kernel via group membership, not routed through the reference monitor.
• Explicit vs. implicit intents: explicit intents name a target component and can be checked by the receiver; implicit intents let the reference monitor choose a suitable, sufficiently-permissioned app.
• Label types: normal permissions are granted silently, dangerous ones require user approval at install time, and signature permissions are only granted to apps signed with the same developer key.
• First-come, first-served labels: because nothing ties a permission string to its "true" owner, a malicious app installed first can define a label's type and description before the legitimate app does.

Walkthrough

Threat model and application components (2:02)

The lecture opens by framing the threat model: malicious apps that want to steal data or trigger paid actions (SMS, calls), and buggy apps written by non-expert developers. It notes Android still has CVE-tracked bugs like buffer overflows and bad crypto defaults, but argues the design keeps these manageable. It then introduces the four component types — activity, service, content provider, broadcast receiver — noting that only one activity receives user input at a time, which helps prevent one app from grabbing another's screen taps.

Manifests, labels and the reference monitor (9:07)

Each app ships with Java code plus a manifest describing its own permissions and the permissions required to reach its components. Cross-app communication happens through intents — structured messages naming a component, an action, and data — routed through a reference monitor that sits between apps and the kernel via a Tor-like pipe mechanism called binder. Class discussion establishes why permission checks live in the reference monitor rather than the sender (an untrusted, possibly compromised app) or the receiver (would require every developer to get the check right): centralizing it in one audited, always-invoked place is simpler and reduces the chance of an app bug leaking a permission check.

Why not desktop or web apps (27:21)

A class discussion compares Android's model to desktop apps (no isolation between installed programs, but easy file sharing between them) and web apps (strong same-origin isolation and easy deployment, but at the time no APIs for phone hardware, limited cross-app sharing, and poor offline support). Android's component model is presented as a middle path: isolated like a web app but with a broker (the reference monitor) that lets apps request specific, mediated interactions with each other and with hardware.

UIDs, GIDs and enforcing permissions outside intents (43:29)

Not everything goes through the reference monitor for performance reasons. Network sockets, SD card access, and direct hardware access (camera, GPS) are gated by Linux kernel group membership instead: a permission string like android.permission.internet maps to a magic GID, and the kernel simply refuses the underlying system call if the calling process lacks that GID. Each app also gets a private directory that only its own UID can read, which is how content-provider databases stay isolated without going through intents at all.

Where permission strings and label types come from (1:00:38)

Labels are not predefined by Android; they are contracts an app defines when it wants to protect one of its own components, and other apps request them by string name. A label carries a type: normal (silently granted), dangerous (shown to the user at install time, who can only accept or reject the whole permission list, not pick individual ones, in the paper's version of Android), and signature (granted only to apps signed with the same key, useful for letting a developer's own apps cooperate without exposing an internal API to everyone).

Weaknesses: label squatting and broadcast receiver authentication (1:10:43)

Because label strings are first-come, first-served and not cryptographically tied to a developer identity, a malicious app installed before a legitimate one can define a sensitive-sounding label as normal with an innocuous description, and the legitimate app is stuck with that definition — Android silently ignores the second definition rather than warning the user. The lecture also covers broadcast receivers: early Android let any app subscribe to any broadcast, so a later addition let senders restrict broadcasts to receivers holding a specific label, and a checkCallingPermission-style function lets a component ask the framework whether a message's sender actually holds a given label, which matters especially for direct RPC channels that bypass the reference monitor after the initial bind.

Before you watch

• Review the earlier Unix lecture and lab on UIDs and file permissions; Android's kernel-level enforcement directly reuses those mechanisms.
• Recall the same-origin policy from the browser security lectures, since it's used as the point of comparison when the lecture asks why Android didn't just build on the web app model.

Check your understanding

1. Why does Android check permissions in a central reference monitor rather than trusting the sending or receiving app to check them?
2. For which kinds of resources does Android bypass the reference monitor and enforce permissions through Linux UIDs and GIDs instead, and why?
3. What is the practical difference between a normal, dangerous, and signature permission label?
4. Explain the "first-come, first-served" label problem: how could a malicious app undermine a legitimate app's permission before it's even installed?
5. Why does Java's role in Android have more to do with portability and developer productivity than with security, according to the lecture?