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
16 but with systems in place that defend against the worst case we'll
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
70 Function pointers and sensitive variables must not be writable
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
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 ------------------------------------
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
152 ---------------------
162 --------------------
167 the kernel's preallocated stack space and into sensitive structures. Two
169 sensitive thread_info structure elsewhere, and adding a faulting memory
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
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
267 Since the locations of sensitive structures are the primary target for
270 addresses or other sensitive things like canary values).
273 ----------------
275 Printing kernel addresses to userspace leaks sensitive information about
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 --------------------
316 it should automatically censor sensitive values.