Introduction

The Android security model is based in part on the concept of application sandboxes. Each application runs in its own sandbox. Prior to Android 4.3, these sandboxes were defined by the creation of a unique Linux UID for each application at time of installation. Starting with Android 4.3, Security-Enhanced Linux (SELinux) is used to further define the boundaries of the Android application sandbox.

As part of the Android security model, Android uses SELinux to enforce mandatory access control (MAC) over all processes, even processes running with root/superuser privileges (a.k.a. Linux capabilities). SELinux enhances Android security by confining privileged processes and automating security policy creation.

Contributions to it have been made by a number of companies and organizations; all Android code and contributors are publicly available for review on android.googlesource.com. With SELinux, Android can better protect and confine system services, control access to application data and system logs, reduce the effects of malicious software, and protect users from potential flaws in code on mobile devices.

Android includes SELinux in enforcing mode and a corresponding security policy that works by default across the Android Open Source Project. In enforcing mode, illegitimate actions are prevented and all attempted violations are logged by the kernel to dmesg and logcat. Android device manufacturers should gather information about errors so they may refine their software and SELinux policies before enforcing them.

Background

SELinux operates on the ethos of default denial. Anything that is not explicitly allowed is denied. SELinux can operate in one of two global modes: permissive mode, in which permission denials are logged but not enforced, and enforcing mode, in which denials are both logged and enforced. SELinux also supports a per-domain permissive mode in which specific domains (processes) can be made permissive while placing the rest of the system in global enforcing mode. A domain is simply a label identifying a process or set of processes in the security policy, where all processes labeled with the same domain are treated identically by the security policy. Per-domain permissive mode enables incremental application of SELinux to an ever-increasing portion of the system. Per-domain permissive mode also enables policy development for new services while keeping the rest of the system enforcing.

In the Android 5.0 (L) release, Android moves to full enforcement of SELinux. This builds upon the permissive release of 4.3 and the partial enforcement of 4.4. In short, Android is shifting from enforcement on a limited set of crucial domains (installd, netd, vold and zygote) to everything (more than 60 domains). This means manufacturers will have to better understand and scale their SELinux implementations to provide compatible devices. Understand that:

Supporting documentation

See the documentation below for details on constructing useful policies:

https://events.linuxfoundation.org/sites/events/files/slides/ abs2014_seforandroid_smalley.pdf

https://www.internetsociety.org/sites/default/files/02_4.pdf

http://freecomputerbooks.com/books/The_SELinux_Notebook-4th_Edition.pdf

http://selinuxproject.org/page/ObjectClassesPerms

https://www.nsa.gov/resources/everyone/digital-media-center/publications/ research-papers/assets/files/ implementing-selinux-as-linux-security-module-report.pdf

https://www.nsa.gov/resources/everyone/digital-media-center/publications/ research-papers/assets/files/configuring-selinux-policy-report.pdf

https://www.gnu.org/software/m4/manual/index.html