Security Enhanced (SE) Android: Bringing Flexible MAC to Android. Stephen Smalley and Robert Craig presented this work at the Network and Distributed System Security Symposium, or NDSS, in 2013. They investigated whether Android could preserve meaningful isolation after a process gained the root user identity. By the end, you should understand how SE Android separates identity from authority, how the prototype was checked against exploit cases and performance measurements, and why the protection still depends on policy quality and kernel security.

Android’s earlier foundation was discretionary access control: access decisions depended on identities such as user IDs and on permissions that owners could change. That created three related problems in the study’s threat model. A privileged daemon could be difficult to confine, an application could weaken permissions on its own files, and a process that became root could escape identity-based isolation. Mandatory policy adds a separate decision layer. A root identity may satisfy an ordinary permission check, but the process must also be in a policy domain that permits the requested operation.

The operational question was whether Android could attach enforceable policy to processes, files, platform services and communication between processes, then use that policy to remove useful steps from an exploit or limit authority afterward. This is useful to defenders because an exploit that produces a process with root as its user identity is not necessarily an unrestricted compromise. The distinction to remember is between obtaining an identity and receiving permission to cross a particular resource or service boundary.

SELinux is the policy layer that checks what each process may access. The implementation added those checks in the kernel, Android user space and Binder, Android’s route for process-to-process calls. The Binder checks governed communication, transfers of references or file descriptors, and which process could become the context manager. For isolation, each process ran in a domain—a policy label used in access decisions. The reference policy confined system daemons and applications, while separate categories isolated each application’s processes and files. The policy occupied 71 kilobytes and covered 39 domains, with every application domain confined.

Across the tested privilege-escalation cases, two outcomes repeated: policy checks blocked individual exploit steps, and processes with root as their user identity still remained confined. For GingerBreak, checks prevented steps such as creating the required netlink socket, executing from writable storage and making a set-user-ID shell. With Mempodroid, a kernel flaw initially allowed an overwrite of run-as memory, but a file check blocked it after run-as received a purpose-built, least-privilege domain. Root-identity processes produced by GingerBreak, Zimperlich and RageAgainstTheCage remained in unprivileged domains without superuser capabilities. Mempodroid likewise gained no SELinux authority without a domain transition.

The researchers also measured implementation cost. Both benchmark suites ran 200 times per build on a Galaxy Nexus. Most SE Android results were described as negligible overhead and stayed within the measured variation of unmodified Android. The system image grew only slightly. These measurements describe performance and storage cost on that prototype and device; they do not measure how many real compromises the mechanism prevents.

The containment was incomplete in a concrete way. In the psneuter test, a missing check allowed the exploit to change shared-memory protections, although its shell still remained confined. More broadly, mandatory access control cannot deny behavior that policy explicitly allows, so broad rules and poorly separated services weaken containment. It also does not generally fix kernel vulnerabilities; policy may sometimes make a vulnerable interface unreachable or reduce the authority gained afterward. The evaluation excluded compromised components with direct memory or storage access, such as a baseband processor, which would require hardware-supported protection.

For Android security architects and policy engineers, the practical unit of analysis is the permitted operation, not the user ID alone. Keep service domains narrow, minimize policy and review broad allow rules. Use neverallow assertions—rules that make forbidden permission combinations fail at build time—together with compatibility tests. Incident responders evaluating an attack chain should record which operation policy denied and what authority the process retained. One denied step is not proof that the whole system is safe: exposed service logic, stale kernels and privileged hardware remain separate concerns.

SE Android demonstrated, in a prototype and a set of exploit cases, that gaining root as a user identity need not grant broader mandatory-policy authority. The useful takeaway for Android platform, vendor and incident-response teams is to evaluate containment one operation and one domain transition at a time, including the authority left after a bypass. They should not infer that SELinux prevents memory corruption, repairs a vulnerable kernel or blocks anything the policy permits. Nor do these results establish an ecosystem-wide percentage of compromises prevented; they establish observable denied steps and retained confinement in the evaluated cases.