Documentation/security/self-protection.rst

2 Kernel Self-Protection
5 Kernel self-protection is the design and implementation of systems and
6 structures within the Linux kernel to protect against security flaws in
7 the kernel itself. This covers a wide range of issues, including removing
9 and actively detecting attack attempts. Not all topics are explored in
13 In the worst-case scenario, we assume an unprivileged local attacker
14 has arbitrary read and write access to the kernel's memory. In many
16 but with systems in place that defend against the worst case we'll
18 still be kept in mind, is protecting the kernel against a _privileged_
21 kernel modules.)
23 The goals for successful self-protection systems would be that they
24 are effective, on by default, require no opt-in by developers, have no
25 performance impact, do not impede kernel debugging, and have tests. It
35 areas of the kernel that can be used to redirect execution. This ranges
36 from limiting the exposed APIs available to userspace, making in-kernel
37 APIs hard to use incorrectly, minimizing the areas of writable kernel
40 Strict kernel memory permissions
41 --------------------------------
43 When all of kernel memory is writable, it becomes trivial for attacks
45 the kernel needs to protect its memory with a tight set of permissions.
47 Executable code and read-only data must not be writable
50 Any areas of the kernel with executable memory must not be writable.
51 While this obviously includes the kernel text itself, we must consider
52 all additional places too: kernel modules, JIT memory, etc. (There are
54 alternatives, breakpoints, kprobes, etc. If these must exist in a
55 kernel, they are implemented in a way where the memory is temporarily
59 In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
61 writable, data is not executable, and read-only data is neither writable
73 Vast areas of kernel memory contain function pointers that are looked
74 up by the kernel and used to continue execution (e.g. descriptor/vector
78 Many such variables can be made read-only by setting them "const"
79 so that they live in the .rodata section instead of the .data section
80 of the kernel, gaining the protection of the kernel's strict memory
88 made to kernel code mentioned above) that allow them to spend the rest
89 of their lifetime read-only. (For example, when being updated, only the
93 Segregation of kernel memory from userspace memory
96 The kernel must never execute userspace memory. The kernel must also never
98 rules can be enforced either by support of hardware-based restrictions
100 By blocking userspace memory in this way, execution and data parsing
101 cannot be passed to trivially-controlled userspace memory, forcing
102 attacks to operate entirely in kernel memory.
105 --------------------------
107 One trivial way to eliminate many syscalls for 64-bit systems is building
110 The "seccomp" system provides an opt-in feature made available to
111 userspace, which provides a way to reduce the number of kernel entry
112 points available to a running process. This limits the breadth of kernel
118 to trusted processes. This would keep the scope of kernel entry points
122 Restricting access to kernel modules
123 ------------------------------------
125 The kernel should never allow an unprivileged user the ability to
126 load specific kernel modules, since that would provide a facility to
127 unexpectedly extend the available attack surface. (The on-demand loading
133 for debate in some scenarios.)
136 disable module loading entirely (e.g. monolithic kernel builds or
138 ``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
139 root load arbitrary kernel code via the module loader interface.
145 There are many memory structures in the kernel that are regularly abused
147 understood is that of the stack buffer overflow in which the return
152 ---------------------
162 --------------------
165 kernel to consume stack memory with deep function calls or large stack
167 the kernel's preallocated stack space and into sensitive structures. Two
173 ---------------------
175 The structures used to track heap free lists can be sanity-checked during
180 -----------------
182 Many places in the kernel use atomic counters to track object references
184 to wrap (over or under) this traditionally exposes a use-after-free
188 -----------------------------------
192 traditionally leads to being able to write past the end of kernel buffers.
198 While many protections can be considered deterministic (e.g. read-only
200 defense, in that an attack must gather enough information about a
205 -------------------------------------
218 working?) in order to maximize their success.
220 Kernel Address Space Layout Randomization (KASLR)
221 -------------------------------------------------
223 Since the location of kernel memory is almost always instrumental in
224 mounting a successful attack, making the location non-deterministic
225 raises the difficulty of an exploit. (Note that this in turn makes
232 By relocating the physical and virtual base address of the kernel at
233 boot-time (``CONFIG_RANDOMIZE_BASE``), attacks needing kernel code will be
235 means that even systems that load the same set of modules in the same
237 the kernel text.
242 If the base address of the kernel stack is not the same between processes,
249 Much of the kernel's dynamic memory (e.g. kmalloc, vmalloc, etc) ends up
250 being relatively deterministic in layout due to the order of early-boot
258 By performing a per-build randomization of the layout of sensitive
259 structures, attacks must either be tuned to known kernel builds or expose
260 enough kernel memory to determine structure layouts before manipulating
268 attacks, it is important to defend against exposure of both kernel memory
269 addresses and kernel memory contents (since they may contain kernel
272 Kernel addresses
273 ----------------
275 Printing kernel addresses to userspace leaks sensitive information about
276 the kernel memory layout. Care should be exercised when using any printk
278 in certain circumstances [*]).  Any file written to using one of these
281 Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
288 ------------------
290 Kernel memory addresses must never be used as identifiers exposed to
295 ---------------------
302 ----------------
308 exposures, heap content exposures, and use-after-free attacks.
311 --------------------
313 To help kill classes of bugs that result in kernel addresses being