1## 9.7\. Security Features 2Device implementations MUST ensure compliance with security features in both the 3kernel and platform as described below. 4 5The Android Sandbox includes features that use the Security-Enhanced Linux 6(SELinux) mandatory access control (MAC) system, seccomp sandboxing, and other 7security features in the Linux kernel. Device implementations: 8 9* [C-0-1] MUST maintain compatibility with existing applications, even when 10SELinux or any other security features are implemented below the Android 11framework. 12* [C-0-2] MUST NOT have a visible user interface when a security 13violation is detected and successfully blocked by the security feature 14implemented below the Android framework, but MAY have a visible user interface 15when an unblocked security violation occurs resulting in a successful exploit. 16* [C-0-3] MUST NOT make SELinux or any other security features implemented 17below the Android framework configurable to the user or app developer. 18* [C-0-4] MUST NOT allow an application that can affect another application 19through an API (such as a Device Administration API) to configure a policy 20that breaks compatibility. 21* [C-0-5] MUST split the media framework into multiple processes so that it 22is possible to more narrowly grant access for each process as 23[described](https://source.android.com/devices/media/framework-hardening.html#arch_changes) 24in the Android Open Source Project site. 25* [C-0-6] MUST implement a kernel application sandboxing mechanism 26which allows filtering of system calls using a configurable policy from 27multithreaded programs. The upstream Android Open Source Project meets this 28requirement through enabling the seccomp-BPF with threadgroup 29synchronization (TSYNC) as described 30[in the Kernel Configuration section of source.android.com](http://source.android.com/devices/tech/config/kernel.html#Seccomp-BPF-TSYNC). 31 32Kernel integrity and self-protection features are integral to Android 33security. Device implementations: 34 35* [C-0-7] MUST implement kernel stack buffer overflow protection mechanisms. 36Examples of such mechanisms are `CC_STACKPROTECTOR_REGULAR` and 37`CONFIG_CC_STACKPROTECTOR_STRONG`. 38* [C-0-8] MUST implement strict kernel memory protections where executable 39code is read-only, read-only data is non-executable and non-writable, and 40writable data is non-executable (e.g. `CONFIG_DEBUG_RODATA` or `CONFIG_STRICT_KERNEL_RWX`). 41* [C-0-9] MUST implement static and dynamic object size 42bounds checking of copies between user-space and kernel-space 43(e.g. `CONFIG_HARDENED_USERCOPY`) on devices originally shipping with API level 4428 or higher. 45* [C-0-10] MUST NOT execute user-space memory when executing 46in the kernel mode (e.g. hardware PXN, or emulated via 47`CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) on devices 48originally shipping with API level 28 or higher. 49* [C-0-11] MUST NOT read or write user-space memory in the 50kernel outside of normal usercopy access APIs (e.g. hardware PAN, or 51emulated via `CONFIG_CPU_SW_DOMAIN_PAN` or `CONFIG_ARM64_SW_TTBR0_PAN`) 52on devices originally shipping with API level 28 or higher. 53* [C-0-12] MUST implement kernel page table isolation if the hardware is 54vulnerable to CVE-2017-5754 on all devices originally shipping with API level 5528 or higher (e.g. `CONFIG_PAGE_TABLE_ISOLATION` or 56`CONFIG_UNMAP_KERNEL_AT_EL0`). 57* [C-0-13] MUST implement branch prediction hardening if the hardware is 58vulnerable to CVE-2017-5715 on all devices originally shipping with API level 5928 or higher (e.g. `CONFIG_HARDEN_BRANCH_PREDICTOR`). 60* [SR] STRONGLY RECOMMENDED to keep kernel data 61which is written only during initialization marked read-only after 62initialization (e.g. `__ro_after_init`). 63* [C-SR] Are STRONGLY RECOMMENDED to randomize the layout of the kernel code and 64memory, and to avoid exposures that would compromise the randomization 65(e.g. `CONFIG_RANDOMIZE_BASE` with bootloader entropy via the 66[`/chosen/kaslr-seed Device Tree node`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/chosen.txt) 67or [`EFI_RNG_PROTOCOL`](https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/efi-rng-protocol)). 68 69* [C-SR] Are STRONGLY RECOMMENDED to enable control flow integrity (CFI) in 70the kernel to provide additional protection against code-reuse attacks 71(e.g. `CONFIG_CFI_CLANG` and `CONFIG_SHADOW_CALL_STACK`). 72* [C-SR] Are STRONGLY RECOMMENDED not to disable Control-Flow Integrity (CFI), 73Shadow Call Stack (SCS) or Integer Overflow Sanitization (IntSan) on 74components that have it enabled. 75* [C-SR] Are STRONGLY RECOMMENDED to enable CFI, SCS, and IntSan for any 76additional security-sensitive userspace components as explained in 77[CFI](https://source.android.com/devices/tech/debug/cfi) and 78[IntSan](https://source.android.com/devices/tech/debug/intsan). 79 80If device implementations use a Linux kernel, they: 81 82* [C-1-1] MUST implement SELinux. 83* [C-1-2] MUST set SELinux to global enforcing mode. 84* [C-1-3] MUST configure all domains in enforcing mode. No permissive mode 85domains are allowed, including domains specific to a device/vendor. 86* [C-1-4] MUST NOT modify, omit, or replace the neverallow rules present 87within the system/sepolicy folder provided in the upstream Android Open Source 88Project (AOSP) and the policy MUST compile with all neverallow rules present, 89for both AOSP SELinux domains as well as device/vendor specific domains. 90* [C-1-5] MUST run third-party applications targeting API level 28 or higher 91in per-application SELinux sandboxes with per-app SELinux restrictions on each 92application's private data directory. 93* SHOULD retain the default SELinux policy provided in the system/sepolicy 94folder of the upstream Android Open Source Project and only further add to this 95policy for their own device-specific configuration. 96 97 98If device implementations use kernel other than Linux, they: 99 100* [C-2-1] MUST use a mandatory access control system that is 101equivalent to SELinux. 102 103Android contains multiple defense-in-depth features that are integral to device 104security. 105