Documentation/process/threat-model.rst

Source file repositories/reference/linux-study-clean/Documentation/process/threat-model.rst

File Facts

System
Linux kernel
Corpus path
Documentation/process/threat-model.rst
Extension
.rst
Size
11627 bytes
Lines
236
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

The Linux Kernel threat model
=============================

There are a lot of assumptions regarding what the kernel does and does not
protect against. These assumptions tend to cause confusion for bug reports
(:doc:`security-related ones <security-bugs>` vs :doc:`non-security ones
<../admin-guide/reporting-issues>`), and can complicate security enforcement
when the responsibilities for some boundaries is not clear between the kernel,
distros, administrators and users.

This document tries to clarify the responsibilities of the kernel in this
domain.

The kernel's responsibilities
-----------------------------

The kernel abstracts access to local hardware resources and to remote systems
in a way that allows multiple local users to get a fair share of the available
resources granted to them, and, when the underlying hardware permits, to assign
a level of confidentiality to their communications and to the data they are
processing or storing.

The kernel assumes that the underlying hardware behaves according to its
specifications. This includes the integrity of the CPU's instruction set, the
transparency of the branch prediction unit and the cache units, the consistency
of the Memory Management Unit (MMU), the isolation of DMA-capable peripherals
(e.g., via IOMMU), state transitions in controllers, ranges of values read from
registers, the respect of documented hardware limitations, etc.

When hardware fails to maintain its specified isolation (e.g., CPU bugs,
side-channels, hardware response to unexpected inputs), the kernel will usually
attempt to implement reasonable mitigations. These are best-effort measures
intended to reduce the attack surface or elevate the cost of an attack within
the limits of the hardware's facilities; they do not constitute a
kernel-provided safety guarantee.

Users always perform their activities under the authority of an administrator
who is able to grant or deny various types of permissions that may affect how
users benefit from available resources, or the level of confidentiality of
their activities. Administrators may also delegate all or part of their own
permissions to some users, particularly via capabilities but not only. All this
is performed via configuration (sysctl, file-system permissions etc).

The Linux Kernel applies a certain collection of default settings that match
its threat model. Distros have their own threat model and will come with their
own configuration presets, that the administrator may have to adjust to better
suit their expectations (relax or restrict).

By default, the Linux Kernel guarantees the following protections when running
on common processors featuring privilege levels and memory management units:

* **User-based isolation**: an unprivileged user may restrict access to their
  own data from other unprivileged users running on the same system. This
  includes:

  * stored data, via file system permissions
  * in-memory data (pages are not accessible by default to other users)
  * process activity (ptrace is not permitted to other users)
  * inter-process communication (other users may not observe data exchanged via
    UNIX domain sockets or other IPC mechanisms).
  * network communications within the same or with other systems

* **Capability-based protection**:

  * users not having elevated capabilities (including but not limited to
    CAP_SYS_ADMIN) may not alter the
    kernel's configuration, memory nor state, change other users' view of the
    file system layout, grant any user capabilities they do not have, nor
    affect the system's availability (shutdown, reboot, panic, hang, or making
    the system unresponsive via unbounded resource exhaustion).

Annotation

Implementation Notes