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
89 made to kernel code mentioned above) that allow them to spend the rest
90 of their lifetime read-only. (For example, when being updated, only the
94 Segregation of kernel memory from userspace memory
97 The kernel must never execute userspace memory. The kernel must also never
99 rules can be enforced either by support of hardware-based restrictions
101 By blocking userspace memory in this way, execution and data parsing
102 cannot be passed to trivially-controlled userspace memory, forcing
103 attacks to operate entirely in kernel memory.
106 --------------------------
108 One trivial way to eliminate many syscalls for 64-bit systems is building
111 The "seccomp" system provides an opt-in feature made available to
112 userspace, which provides a way to reduce the number of kernel entry
113 points available to a running process. This limits the breadth of kernel
119 to trusted processes. This would keep the scope of kernel entry points
123 Restricting access to kernel modules
124 ------------------------------------
126 The kernel should never allow an unprivileged user the ability to
127 load specific kernel modules, since that would provide a facility to
128 unexpectedly extend the available attack surface. (The on-demand loading
134 for debate in some scenarios.)
137 disable module loading entirely (e.g. monolithic kernel builds or
139 ``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
140 root load arbitrary kernel code via the module loader interface.
146 There are many memory structures in the kernel that are regularly abused
148 understood is that of the stack buffer overflow in which the return
153 ---------------------
163 --------------------
166 kernel to consume stack memory with deep function calls or large stack
168 the kernel's preallocated stack space and into sensitive structures. Two
174 ---------------------
176 The structures used to track heap free lists can be sanity-checked during
181 -----------------
183 Many places in the kernel use atomic counters to track object references
185 to wrap (over or under) this traditionally exposes a use-after-free
189 -----------------------------------
193 traditionally leads to being able to write past the end of kernel buffers.
199 While many protections can be considered deterministic (e.g. read-only
201 defense, in that an attack must gather enough information about a
206 -------------------------------------
219 working?) in order to maximize their success.
221 Kernel Address Space Layout Randomization (KASLR)
222 -------------------------------------------------
224 Since the location of kernel memory is almost always instrumental in
225 mounting a successful attack, making the location non-deterministic
226 raises the difficulty of an exploit. (Note that this in turn makes
233 By relocating the physical and virtual base address of the kernel at
234 boot-time (``CONFIG_RANDOMIZE_BASE``), attacks needing kernel code will be
236 means that even systems that load the same set of modules in the same
238 the kernel text.
243 If the base address of the kernel stack is not the same between processes,
250 Much of the kernel's dynamic memory (e.g. kmalloc, vmalloc, etc) ends up
251 being relatively deterministic in layout due to the order of early-boot
259 By performing a per-build randomization of the layout of sensitive
260 structures, attacks must either be tuned to known kernel builds or expose
261 enough kernel memory to determine structure layouts before manipulating
269 attacks, it is important to defend against exposure of both kernel memory
270 addresses and kernel memory contents (since they may contain kernel
273 Kernel addresses
274 ----------------
276 Printing kernel addresses to userspace leaks sensitive information about
277 the kernel memory layout. Care should be exercised when using any printk
279 in certain circumstances [*]).  Any file written to using one of these
282 Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
289 ------------------
291 Kernel memory addresses must never be used as identifiers exposed to
296 ---------------------
303 ----------------
309 exposures, heap content exposures, and use-after-free attacks.
312 --------------------
314 To help kill classes of bugs that result in kernel addresses being