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
dmesg
and
logcat
. When developing, you should
use these errors to refine your software and SELinux policies before enforcing
them. For more details, see
Implementing
SELinux
.
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).
Background
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
domains (
installd
,
netd
,
vold
and
zygote
) to everything (more than 60 domains). Specifically:
- Everything is in enforcing mode in Android 5.x and higher.
- No processes other than
init
should run in the
init
domain.
- Any generic denial (for a
block_device
,
socket_device
,
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
extremely limited
/proc
access.
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 (
vendor.img
,
boot.img
,
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.
Additional resources
For help constructing useful SELinux policies, refer to the following
resources.