docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md

   1 ---
   2 title: Introduction
   3 ---
   4
   5 # Part 4 - Kernel
   6
   7 ## Abstract
   8
   9 **System Hardening:** Best practices associated with the configuration of an
  10 embedded Linux based operating system. This section includes both hardening of
  11 the kernel itself, as well as specific configurations and patches used to
  12 protect against known vulnerabilities within the build and configuration of the
  13 root filesystem.
  14
  15 At the Kernel level, we must ensure that no console can be launched. It could be
  16 used to change the behavior of the system or to have more information about it.
  17 Another aspect is the protection of the memory used by the Kernel.
  18
  19 The next sub-sections contain information on various kernel configuration
  20 options to enhance the security in the kernel (3.10.17) and also for
  21 applications compiled to take advantage of these security features.
  22 Additionally, there are also configuration options that protect from known
  23 vulnerable configuration options. Here's a high level summary of various kernel
  24 configurations that shall be required for deployment.
  25
  26 ## Kernel Version
  27
  28 The choice of kernel version for the AGL system is essential to its security.
  29 Depending on the type of board and eventual production system, different kernel
  30 versions are used. For example, one of the systems under study uses the Linux
  31 kernel version 3.10, while another uses the Linux kernel version 4.4. For the
  32 Linux kernel version 3.10.31, there are 25 known vulnerabilities. These
  33 vulnerabilities would allow an attacker to gain privileges, bypass access
  34 restrictions, allow memory to be corrupted, or cause denial of service. In
  35 contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities.
  36 For this reason, we would in general recommend the later kernel version as a
  37 basis for the platform.
  38
  39 Note that, although there are fewer known vulnerabilities in the most recent
  40 kernel versions there may be many unknown vulnerabilities underlying. A rule of
  41 thumb is to update the kernel as much as possible to avoid the problems you do
  42 know, but you should not be complacent in the trust that you place in it. A
  43 defense-in-depth approach would then apply.
  44
  45 If there are constraints and dependencies in upgrading to a newer kernel version
  46 (e.g. device drivers, board support providers) and you are forced to an older
  47 Linux kernel version, there need to be additional provisions made to reduce the
  48 risk of kernel exploits, which can include memory monitoring, watch-dog
  49 services, and system call hooking. In this case, further defense-in-depth
  50 techniques may be required to mitigate the risk of attacks to known
  51 vulnerabilities, which can also include runtime integrity verification of
  52 components that are vulnerable to tampering.
  53
  54 ## Kernel Build Configuration
  55
  56 The kernel build configuration is extremely important for determining the level
  57 of access to services and to reduce the breadth of the attack surface. Linux
  58 contains a great and flexible number of capabilities and this is only controlled
  59 through the build configuration. For example, the `CONFIG_MODULES` parameter
  60 allows kernel modules to be loaded at runtime extending the capabilities of the
  61 kernel. This capability needs to be either inhibited or controlled at runtime
  62 through other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y`
  63 ensures that only signed modules are loaded. There is a very large number of
  64 kernel configuration parameters, and these are discussed in detail in this
  65 section.