1 files changed, 0 insertions, 65 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
deleted file mode 100644
index 4f23b13..0000000
--- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/4_Kernel/1.2.4.0_Abstract.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Introduction
----
-
-# 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.