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