As part of the Android security model, Android uses Security-Enhanced Linux (SELinux) to enforce mandatory access control (MAC) over all processes, even processes running with root/superuser privileges (Linux capabilities). Many companies and organizations have contributed to Android's SELinux implementation. 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.
SELinux operates on the principle of default denial: Anything not explicitly allowed is denied. SELinux can operate in two global modes:
- Permissive mode, in which permission denials are logged but not enforced.
- Enforcing mode, in which permissions denials are both logged and enforced.
Android includes SELinux in enforcing mode and a corresponding security
policy that works by default across AOSP. In enforcing mode, disallowed
actions are prevented and all attempted violations are logged by the kernel to
logcat. When developing, you should
use these errors to refine your software and SELinux policies before enforcing
them. For more details, see Implementing
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 and policy development for new services (while keeping the rest of the system enforcing).
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. Android 4.3 and later uses SELinux to further define the boundaries of the Android application sandbox.
In Android 5.0 and later, SELinux is fully enforced, building on the
permissive release of Android 4.3 and the partial enforcement of Android 4.4.
With this change, Android shifted from enforcement on a limited set of crucial
zygote) to everything (more than 60 domains). Specifically:
- Everything is in enforcing mode in Android 5.x and higher.
- No processes other than
initshould run in the
- Any generic denial (for a
default_service) indicates that device needs a special domain.
Android 6.0 hardened the system by reducing the permissiveness of our
policy to include better isolation between users, IOCTL filtering, reduced
threat of exposed services, further tightening of SELinux domains, and
Android 7.0 updated SELinux configuration to further lock down the application sandbox and reduce attack surface. This release also broke up the monolithic mediaserver stack into smaller processes to reduce the scope of their permissions. For more details, see Protecting Android with more Linux kernel defenses and Hardening the media stack.
Android 8.0 updated SELinux to work with Treble, which separates the lower-level
vendor code from the Android system framework. This release updated SELinux
policy to allow device manufacturers and SOC vendors to update their parts of
the policy, build their images (
etc.), then update those images independent of the platform or vice versa.
While it is possible to have higher/newer platform (framework) version
running on the device, the opposite case is not supported; the vendor images
vendor.img/odm.img) cannot have a newer version than the platform
system.img). So, a newer platform version might introduce SELinux
compatibility issues because the platform SELinux policy is at a newer version
than vendor SELinux parts of the policy. The Android 8.0 model provides a method
to retain compatibility to prevent
unnecessary simultaneous OTAs.
For help constructing useful SELinux policies, refer to the following resources. Some SELinux concepts are not used by Android, see the Specificity section when considering external documentation.
- The SELinux Notebook, up-to-date reference for SELinux. It contains further details on the policy language, the meaning of each keywords and how security contexts are computed.
- Your visual how-to guide for SELinux policy enforcement
- Security Enhancements for Linux
- Security Enhanced (SE) Android: Bringing Flexible MAC to Android
- Implementing SELinux as a Linux Security Module
- Configuring the SELinux Policy