Lines Matching +full:many +full:- +full:to +full:- +full:many

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
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
19 local attacker, since the root user has access to a vastly increased
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
27 mentioning them, since these aspects need to be explored, dealt with,
34 The most fundamental defense against security exploits is to reduce the
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
41 --------------------------------
44 to redirect execution flow. To reduce the availability of these targets
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
53 temporary exceptions to this rule to support things like instruction
56 made writable during the update, and then returned to the original
60 ``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not
61 writable, data is not executable, and read-only data is neither writable
65 For some architectures like arm that wish to have these be selectable,
66 the architecture Kconfig can select ARCH_OPTIONAL_KERNEL_RWX to enable
74 up by the kernel and used to continue execution (e.g. descriptor/vector
76 variables must be reduced to an absolute minimum.
78 Many such variables can be made read-only by setting them "const"
87 will need another infrastructure (similar to the temporary exceptions
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
91 access to the memory.)
97 access userspace memory without explicit expectation to do so. These
98 rules can be enforced either by support of hardware-based restrictions
101 cannot be passed to trivially-controlled userspace memory, forcing
102 attacks to operate entirely in kernel memory.
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
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
114 bug to an attack.
116 An area of improvement would be creating viable ways to keep access to
118 to trusted processes. This would keep the scope of kernel entry points
119 restricted to the more regular set of normally available to unprivileged
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
130 given even to these.) For example, loading a filesystem module via an
135 To protect against even privileged users, systems may need to either
138 ``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
145 There are many memory structures in the kernel that are regularly abused
146 to gain execution control during an attack, By far the most commonly
148 address stored on the stack is overwritten. Many other examples of this
149 kind of attack exist, and protections exist to defend against them.
152 ---------------------
156 to the stack frame's stored return address. The most widely used defense
162 --------------------
165 kernel to consume stack memory with deep function calls or large stack
166 allocations. With this attack it is possible to write beyond the end of
168 important changes need to be made for better protections: moving the
170 hole at the bottom of the stack to catch these overflows.
173 ---------------------
175 The structures used to track heap free lists can be sanity-checked during
176 allocation and freeing to make sure they aren't being used to manipulate
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 -----------------------------------
190 Similar to counter overflow, integer overflows (usually size calculations)
191 need to be detected at runtime to kill this class of bug, which
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
199 memory cannot be written to), some protections provide only statistical
201 running system to overcome the defense. While not perfect, these do
205 -------------------------------------
218 working?) in order to maximize their success.
221 -------------------------------------------------
224 mounting a successful attack, making the location non-deterministic
226 the value of information exposures higher, since they may be used to
233 boot-time (``CONFIG_RANDOMIZE_BASE``), attacks needing kernel code will be
244 become more difficult to locate.
250 being relatively deterministic in layout due to the order of early-boot
253 exposure specific to the region.
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
273 ----------------
275 Printing kernel addresses to userspace leaks sensitive information about
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 ---------------------
297 Memory copied to userspace must always be fully initialized. If not
298 explicitly memset(), this will require changes to the compiler to make
302 ----------------
304 When releasing memory, it is best to poison the contents, to avoid reuse
307 free. This frustrates many uninitialized variable attacks, stack content
308 exposures, heap content exposures, and use-after-free attacks.
311 --------------------
313 To help kill classes of bugs that result in kernel addresses being
314 written to userspace, the destination of writes needs to be tracked. If