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

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
17 cover the more limited cases as well. A higher bar, and one that should
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"
88 will need another infrastructure (similar to the temporary exceptions
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
92 access to the memory.)
98 access userspace memory without explicit expectation to do so. These
99 rules can be enforced either by support of hardware-based restrictions
102 cannot be passed to trivially-controlled userspace memory, forcing
103 attacks to operate entirely in kernel memory.
105 Reduced access to syscalls
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
115 bug to an attack.
117 An area of improvement would be creating viable ways to keep access to
119 to trusted processes. This would keep the scope of kernel entry points
120 restricted to the more regular set of normally available to unprivileged
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
131 given even to these.) For example, loading a filesystem module via an
136 To protect against even privileged users, systems may need to either
139 ``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
146 There are many memory structures in the kernel that are regularly abused
147 to gain execution control during an attack, By far the most commonly
149 address stored on the stack is overwritten. Many other examples of this
150 kind of attack exist, and protections exist to defend against them.
153 ---------------------
157 to the stack frame's stored return address. The most widely used defense
163 --------------------
166 kernel to consume stack memory with deep function calls or large stack
167 allocations. With this attack it is possible to write beyond the end of
169 important changes need to be made for better protections: moving the
171 hole at the bottom of the stack to catch these overflows.
174 ---------------------
176 The structures used to track heap free lists can be sanity-checked during
177 allocation and freeing to make sure they aren't being used to manipulate
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 -----------------------------------
191 Similar to counter overflow, integer overflows (usually size calculations)
192 need to be detected at runtime to kill this class of bug, which
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
200 memory cannot be written to), some protections provide only statistical
202 running system to overcome the defense. While not perfect, these do
206 -------------------------------------
219 working?) in order to maximize their success.
222 -------------------------------------------------
225 mounting a successful attack, making the location non-deterministic
227 the value of information exposures higher, since they may be used to
234 boot-time (``CONFIG_RANDOMIZE_BASE``), attacks needing kernel code will be
245 become more difficult to locate.
251 being relatively deterministic in layout due to the order of early-boot
254 exposure specific to the region.
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
274 ----------------
276 Printing kernel addresses to userspace leaks sensitive information about
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 ---------------------
298 Memory copied to userspace must always be fully initialized. If not
299 explicitly memset(), this will require changes to the compiler to make
303 ----------------
305 When releasing memory, it is best to poison the contents, to avoid reuse
308 free. This frustrates many uninitialized variable attacks, stack content
309 exposures, heap content exposures, and use-after-free attacks.
312 --------------------
314 To help kill classes of bugs that result in kernel addresses being
315 written to userspace, the destination of writes needs to be tracked. If