1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
# 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.
|
