mirror of https://gitee.com/openkylin/linux.git
303 lines
13 KiB
ReStructuredText
303 lines
13 KiB
ReStructuredText
|
======================
|
||
|
Kernel Self-Protection
|
||
|
======================
|
||
|
|
||
|
Kernel self-protection is the design and implementation of systems and
|
||
|
structures within the Linux kernel to protect against security flaws in
|
||
|
the kernel itself. This covers a wide range of issues, including removing
|
||
|
entire classes of bugs, blocking security flaw exploitation methods,
|
||
|
and actively detecting attack attempts. Not all topics are explored in
|
||
|
this document, but it should serve as a reasonable starting point and
|
||
|
answer any frequently asked questions. (Patches welcome, of course!)
|
||
|
|
||
|
In the worst-case scenario, we assume an unprivileged local attacker
|
||
|
has arbitrary read and write access to the kernel's memory. In many
|
||
|
cases, bugs being exploited will not provide this level of access,
|
||
|
but with systems in place that defend against the worst case we'll
|
||
|
cover the more limited cases as well. A higher bar, and one that should
|
||
|
still be kept in mind, is protecting the kernel against a _privileged_
|
||
|
local attacker, since the root user has access to a vastly increased
|
||
|
attack surface. (Especially when they have the ability to load arbitrary
|
||
|
kernel modules.)
|
||
|
|
||
|
The goals for successful self-protection systems would be that they
|
||
|
are effective, on by default, require no opt-in by developers, have no
|
||
|
performance impact, do not impede kernel debugging, and have tests. It
|
||
|
is uncommon that all these goals can be met, but it is worth explicitly
|
||
|
mentioning them, since these aspects need to be explored, dealt with,
|
||
|
and/or accepted.
|
||
|
|
||
|
|
||
|
Attack Surface Reduction
|
||
|
========================
|
||
|
|
||
|
The most fundamental defense against security exploits is to reduce the
|
||
|
areas of the kernel that can be used to redirect execution. This ranges
|
||
|
from limiting the exposed APIs available to userspace, making in-kernel
|
||
|
APIs hard to use incorrectly, minimizing the areas of writable kernel
|
||
|
memory, etc.
|
||
|
|
||
|
Strict kernel memory permissions
|
||
|
--------------------------------
|
||
|
|
||
|
When all of kernel memory is writable, it becomes trivial for attacks
|
||
|
to redirect execution flow. To reduce the availability of these targets
|
||
|
the kernel needs to protect its memory with a tight set of permissions.
|
||
|
|
||
|
Executable code and read-only data must not be writable
|
||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
||
|
Any areas of the kernel with executable memory must not be writable.
|
||
|
While this obviously includes the kernel text itself, we must consider
|
||
|
all additional places too: kernel modules, JIT memory, etc. (There are
|
||
|
temporary exceptions to this rule to support things like instruction
|
||
|
alternatives, breakpoints, kprobes, etc. If these must exist in a
|
||
|
kernel, they are implemented in a way where the memory is temporarily
|
||
|
made writable during the update, and then returned to the original
|
||
|
permissions.)
|
||
|
|
||
|
In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
|
||
|
``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not
|
||
|
writable, data is not executable, and read-only data is neither writable
|
||
|
nor executable.
|
||
|
|
||
|
Most architectures have these options on by default and not user selectable.
|
||
|
For some architectures like arm that wish to have these be selectable,
|
||
|
the architecture Kconfig can select ARCH_OPTIONAL_KERNEL_RWX to enable
|
||
|
a Kconfig prompt. ``CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT`` determines
|
||
|
the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled.
|
||
|
|
||
|
Function pointers and sensitive variables must not be writable
|
||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
||
|
Vast areas of kernel memory contain function pointers that are looked
|
||
|
up by the kernel and used to continue execution (e.g. descriptor/vector
|
||
|
tables, file/network/etc operation structures, etc). The number of these
|
||
|
variables must be reduced to an absolute minimum.
|
||
|
|
||
|
Many such variables can be made read-only by setting them "const"
|
||
|
so that they live in the .rodata section instead of the .data section
|
||
|
of the kernel, gaining the protection of the kernel's strict memory
|
||
|
permissions as described above.
|
||
|
|
||
|
For variables that are initialized once at ``__init`` time, these can
|
||
|
be marked with the (new and under development) ``__ro_after_init``
|
||
|
attribute.
|
||
|
|
||
|
What remains are variables that are updated rarely (e.g. GDT). These
|
||
|
will need another infrastructure (similar to the temporary exceptions
|
||
|
made to kernel code mentioned above) that allow them to spend the rest
|
||
|
of their lifetime read-only. (For example, when being updated, only the
|
||
|
CPU thread performing the update would be given uninterruptible write
|
||
|
access to the memory.)
|
||
|
|
||
|
Segregation of kernel memory from userspace memory
|
||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
||
|
The kernel must never execute userspace memory. The kernel must also never
|
||
|
access userspace memory without explicit expectation to do so. These
|
||
|
rules can be enforced either by support of hardware-based restrictions
|
||
|
(x86's SMEP/SMAP, ARM's PXN/PAN) or via emulation (ARM's Memory Domains).
|
||
|
By blocking userspace memory in this way, execution and data parsing
|
||
|
cannot be passed to trivially-controlled userspace memory, forcing
|
||
|
attacks to operate entirely in kernel memory.
|
||
|
|
||
|
Reduced access to syscalls
|
||
|
--------------------------
|
||
|
|
||
|
One trivial way to eliminate many syscalls for 64-bit systems is building
|
||
|
without ``CONFIG_COMPAT``. However, this is rarely a feasible scenario.
|
||
|
|
||
|
The "seccomp" system provides an opt-in feature made available to
|
||
|
userspace, which provides a way to reduce the number of kernel entry
|
||
|
points available to a running process. This limits the breadth of kernel
|
||
|
code that can be reached, possibly reducing the availability of a given
|
||
|
bug to an attack.
|
||
|
|
||
|
An area of improvement would be creating viable ways to keep access to
|
||
|
things like compat, user namespaces, BPF creation, and perf limited only
|
||
|
to trusted processes. This would keep the scope of kernel entry points
|
||
|
restricted to the more regular set of normally available to unprivileged
|
||
|
userspace.
|
||
|
|
||
|
Restricting access to kernel modules
|
||
|
------------------------------------
|
||
|
|
||
|
The kernel should never allow an unprivileged user the ability to
|
||
|
load specific kernel modules, since that would provide a facility to
|
||
|
unexpectedly extend the available attack surface. (The on-demand loading
|
||
|
of modules via their predefined subsystems, e.g. MODULE_ALIAS_*, is
|
||
|
considered "expected" here, though additional consideration should be
|
||
|
given even to these.) For example, loading a filesystem module via an
|
||
|
unprivileged socket API is nonsense: only the root or physically local
|
||
|
user should trigger filesystem module loading. (And even this can be up
|
||
|
for debate in some scenarios.)
|
||
|
|
||
|
To protect against even privileged users, systems may need to either
|
||
|
disable module loading entirely (e.g. monolithic kernel builds or
|
||
|
modules_disabled sysctl), or provide signed modules (e.g.
|
||
|
``CONFIG_MODULE_SIG_FORCE``, or dm-crypt with LoadPin), to keep from having
|
||
|
root load arbitrary kernel code via the module loader interface.
|
||
|
|
||
|
|
||
|
Memory integrity
|
||
|
================
|
||
|
|
||
|
There are many memory structures in the kernel that are regularly abused
|
||
|
to gain execution control during an attack, By far the most commonly
|
||
|
understood is that of the stack buffer overflow in which the return
|
||
|
address stored on the stack is overwritten. Many other examples of this
|
||
|
kind of attack exist, and protections exist to defend against them.
|
||
|
|
||
|
Stack buffer overflow
|
||
|
---------------------
|
||
|
|
||
|
The classic stack buffer overflow involves writing past the expected end
|
||
|
of a variable stored on the stack, ultimately writing a controlled value
|
||
|
to the stack frame's stored return address. The most widely used defense
|
||
|
is the presence of a stack canary between the stack variables and the
|
||
|
return address (``CONFIG_CC_STACKPROTECTOR``), which is verified just before
|
||
|
the function returns. Other defenses include things like shadow stacks.
|
||
|
|
||
|
Stack depth overflow
|
||
|
--------------------
|
||
|
|
||
|
A less well understood attack is using a bug that triggers the
|
||
|
kernel to consume stack memory with deep function calls or large stack
|
||
|
allocations. With this attack it is possible to write beyond the end of
|
||
|
the kernel's preallocated stack space and into sensitive structures. Two
|
||
|
important changes need to be made for better protections: moving the
|
||
|
sensitive thread_info structure elsewhere, and adding a faulting memory
|
||
|
hole at the bottom of the stack to catch these overflows.
|
||
|
|
||
|
Heap memory integrity
|
||
|
---------------------
|
||
|
|
||
|
The structures used to track heap free lists can be sanity-checked during
|
||
|
allocation and freeing to make sure they aren't being used to manipulate
|
||
|
other memory areas.
|
||
|
|
||
|
Counter integrity
|
||
|
-----------------
|
||
|
|
||
|
Many places in the kernel use atomic counters to track object references
|
||
|
or perform similar lifetime management. When these counters can be made
|
||
|
to wrap (over or under) this traditionally exposes a use-after-free
|
||
|
flaw. By trapping atomic wrapping, this class of bug vanishes.
|
||
|
|
||
|
Size calculation overflow detection
|
||
|
-----------------------------------
|
||
|
|
||
|
Similar to counter overflow, integer overflows (usually size calculations)
|
||
|
need to be detected at runtime to kill this class of bug, which
|
||
|
traditionally leads to being able to write past the end of kernel buffers.
|
||
|
|
||
|
|
||
|
Probabilistic defenses
|
||
|
======================
|
||
|
|
||
|
While many protections can be considered deterministic (e.g. read-only
|
||
|
memory cannot be written to), some protections provide only statistical
|
||
|
defense, in that an attack must gather enough information about a
|
||
|
running system to overcome the defense. While not perfect, these do
|
||
|
provide meaningful defenses.
|
||
|
|
||
|
Canaries, blinding, and other secrets
|
||
|
-------------------------------------
|
||
|
|
||
|
It should be noted that things like the stack canary discussed earlier
|
||
|
are technically statistical defenses, since they rely on a secret value,
|
||
|
and such values may become discoverable through an information exposure
|
||
|
flaw.
|
||
|
|
||
|
Blinding literal values for things like JITs, where the executable
|
||
|
contents may be partially under the control of userspace, need a similar
|
||
|
secret value.
|
||
|
|
||
|
It is critical that the secret values used must be separate (e.g.
|
||
|
different canary per stack) and high entropy (e.g. is the RNG actually
|
||
|
working?) in order to maximize their success.
|
||
|
|
||
|
Kernel Address Space Layout Randomization (KASLR)
|
||
|
-------------------------------------------------
|
||
|
|
||
|
Since the location of kernel memory is almost always instrumental in
|
||
|
mounting a successful attack, making the location non-deterministic
|
||
|
raises the difficulty of an exploit. (Note that this in turn makes
|
||
|
the value of information exposures higher, since they may be used to
|
||
|
discover desired memory locations.)
|
||
|
|
||
|
Text and module base
|
||
|
~~~~~~~~~~~~~~~~~~~~
|
||
|
|
||
|
By relocating the physical and virtual base address of the kernel at
|
||
|
boot-time (``CONFIG_RANDOMIZE_BASE``), attacks needing kernel code will be
|
||
|
frustrated. Additionally, offsetting the module loading base address
|
||
|
means that even systems that load the same set of modules in the same
|
||
|
order every boot will not share a common base address with the rest of
|
||
|
the kernel text.
|
||
|
|
||
|
Stack base
|
||
|
~~~~~~~~~~
|
||
|
|
||
|
If the base address of the kernel stack is not the same between processes,
|
||
|
or even not the same between syscalls, targets on or beyond the stack
|
||
|
become more difficult to locate.
|
||
|
|
||
|
Dynamic memory base
|
||
|
~~~~~~~~~~~~~~~~~~~
|
||
|
|
||
|
Much of the kernel's dynamic memory (e.g. kmalloc, vmalloc, etc) ends up
|
||
|
being relatively deterministic in layout due to the order of early-boot
|
||
|
initializations. If the base address of these areas is not the same
|
||
|
between boots, targeting them is frustrated, requiring an information
|
||
|
exposure specific to the region.
|
||
|
|
||
|
Structure layout
|
||
|
~~~~~~~~~~~~~~~~
|
||
|
|
||
|
By performing a per-build randomization of the layout of sensitive
|
||
|
structures, attacks must either be tuned to known kernel builds or expose
|
||
|
enough kernel memory to determine structure layouts before manipulating
|
||
|
them.
|
||
|
|
||
|
|
||
|
Preventing Information Exposures
|
||
|
================================
|
||
|
|
||
|
Since the locations of sensitive structures are the primary target for
|
||
|
attacks, it is important to defend against exposure of both kernel memory
|
||
|
addresses and kernel memory contents (since they may contain kernel
|
||
|
addresses or other sensitive things like canary values).
|
||
|
|
||
|
Unique identifiers
|
||
|
------------------
|
||
|
|
||
|
Kernel memory addresses must never be used as identifiers exposed to
|
||
|
userspace. Instead, use an atomic counter, an idr, or similar unique
|
||
|
identifier.
|
||
|
|
||
|
Memory initialization
|
||
|
---------------------
|
||
|
|
||
|
Memory copied to userspace must always be fully initialized. If not
|
||
|
explicitly memset(), this will require changes to the compiler to make
|
||
|
sure structure holes are cleared.
|
||
|
|
||
|
Memory poisoning
|
||
|
----------------
|
||
|
|
||
|
When releasing memory, it is best to poison the contents (clear stack on
|
||
|
syscall return, wipe heap memory on a free), to avoid reuse attacks that
|
||
|
rely on the old contents of memory. This frustrates many uninitialized
|
||
|
variable attacks, stack content exposures, heap content exposures, and
|
||
|
use-after-free attacks.
|
||
|
|
||
|
Destination tracking
|
||
|
--------------------
|
||
|
|
||
|
To help kill classes of bugs that result in kernel addresses being
|
||
|
written to userspace, the destination of writes needs to be tracked. If
|
||
|
the buffer is destined for userspace (e.g. seq_file backed ``/proc`` files),
|
||
|
it should automatically censor sensitive values.
|