Documentation/security/self-protection.rst

2 Kernel Self-Protection
5 Kernel self-protection is the design and implementation of systems and
13 In the worst-case scenario, we assume an unprivileged local attacker
20 attack surface. (Especially when they have the ability to load arbitrary
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
36 from limiting the exposed APIs available to userspace, making in-kernel
41 --------------------------------
47 Executable code and read-only data must not be writable
61 writable, data is not executable, and read-only data is neither writable
76 variables must be reduced to an absolute minimum.
78 Many such variables can be made read-only by setting them "const"
89 of their lifetime read-only. (For example, when being updated, only the
98 rules can be enforced either by support of hardware-based restrictions
101 cannot be passed to trivially-controlled userspace memory, forcing
104 Reduced access to syscalls
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
123 ------------------------------------
126 load specific kernel modules, since that would provide a facility to
127 unexpectedly extend the available attack surface. (The on-demand loading
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.
152 ---------------------
162 --------------------
173 ---------------------
175 The structures used to track heap free lists can be sanity-checked during
180 -----------------
184 to wrap (over or under) this traditionally exposes a use-after-free
188 -----------------------------------
198 While many protections can be considered deterministic (e.g. read-only
205 -------------------------------------
221 -------------------------------------------------
224 mounting a successful attack, making the location non-deterministic
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
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
273 ----------------
281 Kernels 4.14 and older printed the raw address using %p. As of 4.15-rc1
288 ------------------
295 ---------------------
302 ----------------
308 exposures, heap content exposures, and use-after-free attacks.
311 --------------------