Added content from the hidden chapter of the "old" security-blueprint.

1 files changed, 40 insertions, 0 deletions

diff --git a/security-blueprint/part-4/0_Abstract.md b/security-blueprint/part-4/0_Abstract.md
index edf75be..01957e4 100644
--- a/security-blueprint/part-4/0_Abstract.md
+++ b/security-blueprint/part-4/0_Abstract.md
@@ -18,3 +18,43 @@ 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.