Lines Matching +full:user +full:- +full:selectable

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
19 local attacker, since the root user has access to a vastly increased
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
64 Most architectures have these options on by default and not user selectable.
65 For some architectures like arm that wish to have these be selectable,
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
117 things like compat, user namespaces, BPF creation, and perf limited only
123 ------------------------------------
125 The kernel should never allow an unprivileged user the ability to
127 unexpectedly extend the available attack surface. (The on-demand loading
132 user should trigger filesystem module loading. (And even this can be up
138 ``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
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
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 --------------------