diff options
Diffstat (limited to 'docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md')
| -rw-r--r-- | docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md | 69 |
1 files changed, 69 insertions, 0 deletions
diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md new file mode 100644 index 0000000..cff791b --- /dev/null +++ b/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md @@ -0,0 +1,69 @@ +--- +edit_link: '' +title: Introduction +origin_url: >- + https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-4/0_Abstract.md +--- + +<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml --> + +# Part 4 - Kernel + +## Abstract + +**System Hardening:** Best practices associated with the configuration of an +embedded Linux based operating system. This section includes both hardening of +the kernel itself, as well as specific configurations and patches used to +protect against known vulnerabilities within the build and configuration of the +root filesystem. + +At the Kernel level, we must ensure that no console can be launched. It could be +used to change the behavior of the system or to have more information about it. +Another aspect is the protection of the memory used by the Kernel. + +The next sub-sections contain information on various kernel configuration +options to enhance the security in the kernel (3.10.17) and also for +applications compiled to take advantage of these security features. +Additionally, there are also configuration options that protect from known +vulnerable configuration options. Here's a high level summary of various kernel +configurations that shall be required for deployment. + +## Kernel Version + +The choice of kernel version for the AGL system is essential to its security. +Depending on the type of board and eventual production system, different kernel +versions are used. For example, one of the systems under study uses the +Linux kernel version 3.10, while another uses the Linux kernel version 4.4. +For the Linux kernel version 3.10.31, there are 25 known vulnerabilities. +These vulnerabilities would allow an attacker to gain privileges, +bypass access restrictions, allow memory to be corrupted, or cause denial of service. +In contrast, the Linux kernel version of 4.4 has many fewer known vulnerabilities. +For this reason, we would in general recommend the later kernel version as a basis +for the platform. + +Note that, although there are fewer known vulnerabilities in the most recent kernel +versions there may be many unknown vulnerabilities underlying. +A rule of thumb is to update the kernel as much as possible to avoid the problems +you do know, but you should not be complacent in the trust that you place in it. +A defense-in-depth approach would then apply. + +If there are constraints and dependencies in upgrading to a newer kernel version +(e.g. device drivers, board support providers) and you are forced to an older +Linux kernel version, there need to be additional provisions made to reduce +the risk of kernel exploits, which can include memory monitoring, watch-dog services, +and system call hooking. In this case, further defense-in-depth techniques +may be required to mitigate the risk of attacks to known vulnerabilities, +which can also include runtime integrity verification of components +that are vulnerable to tampering. + +## Kernel Build Configuration + +The kernel build configuration is extremely important for determining the level +of access to services and to reduce the breadth of the attack surface. +Linux contains a great and flexible number of capabilities and this is only controlled +through the build configuration. For example, the `CONFIG_MODULES` parameter +allows kernel modules to be loaded at runtime extending the capabilities of the kernel. +This capability needs to be either inhibited or controlled at runtime through +other configuration parameters. For example, `CONFIG_MODULE_SIG_FORCE=y` ensures +that only signed modules are loaded. There is a very large number of kernel +configuration parameters, and these are discussed in detail in this section. |