<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Credentials in Linux — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="Confidential Computing in Linux for x86 virtualization" href="snp-tdx-threat-model.html" />
<link rel="prev" title="Security Documentation" href="index.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#human-interfaces">Human interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#networking-interfaces">Networking interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../subsystem-apis.html#other-subsystems">Other subsystems</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="../accounting/index.html">Accounting</a></li>
<li class="toctree-l3"><a class="reference internal" href="../cpu-freq/index.html">CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel</a></li>
<li class="toctree-l3"><a class="reference internal" href="../edac/index.html">EDAC Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../fpga/index.html">FPGA</a></li>
<li class="toctree-l3"><a class="reference internal" href="../i2c/index.html">I2C/SMBus Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../iio/index.html">Industrial I/O</a></li>
<li class="toctree-l3"><a class="reference internal" href="../pcmcia/index.html">PCMCIA</a></li>
<li class="toctree-l3"><a class="reference internal" href="../spi/index.html">Serial Peripheral Interface (SPI)</a></li>
<li class="toctree-l3"><a class="reference internal" href="../w1/index.html">1-Wire Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../watchdog/index.html">Watchdog Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../virt/index.html">Virtualization Support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../hwmon/index.html">Hardware Monitoring</a></li>
<li class="toctree-l3"><a class="reference internal" href="../accel/index.html">Compute Accelerators</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="index.html">Security Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../crypto/index.html">Crypto API</a></li>
<li class="toctree-l3"><a class="reference internal" href="../bpf/index.html">BPF Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../usb/index.html">USB support</a></li>
<li class="toctree-l3"><a class="reference internal" href="../PCI/index.html">PCI Bus Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../misc-devices/index.html">Assorted Miscellaneous Devices Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../peci/index.html">PECI Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../wmi/index.html">WMI Subsystem</a></li>
<li class="toctree-l3"><a class="reference internal" href="../tee/index.html">TEE Subsystem</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/security/credentials.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="language-selection">
English
<ul>
<li><a href="../translations/zh_CN/security/credentials.html">Chinese (Simplified)</a></li>
</ul>
</div>
<section id="credentials-in-linux">
<h1>Credentials in Linux<a class="headerlink" href="#credentials-in-linux" title="Link to this heading">¶</a></h1>
<p>By: David Howells <<a class="reference external" href="mailto:dhowells%40redhat.com">dhowells<span>@</span>redhat<span>.</span>com</a>></p>
<nav class="contents local" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#overview" id="id1">Overview</a></p></li>
<li><p><a class="reference internal" href="#types-of-credentials" id="id2">Types of Credentials</a></p></li>
<li><p><a class="reference internal" href="#file-markings" id="id3">File Markings</a></p></li>
<li><p><a class="reference internal" href="#task-credentials" id="id4">Task Credentials</a></p>
<ul>
<li><p><a class="reference internal" href="#immutable-credentials" id="id5">Immutable Credentials</a></p></li>
<li><p><a class="reference internal" href="#accessing-task-credentials" id="id6">Accessing Task Credentials</a></p></li>
<li><p><a class="reference internal" href="#accessing-another-task-s-credentials" id="id7">Accessing Another Task’s Credentials</a></p></li>
<li><p><a class="reference internal" href="#altering-credentials" id="id8">Altering Credentials</a></p></li>
<li><p><a class="reference internal" href="#managing-credentials" id="id9">Managing Credentials</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#open-file-credentials" id="id10">Open File Credentials</a></p></li>
<li><p><a class="reference internal" href="#overriding-the-vfs-s-use-of-credentials" id="id11">Overriding the VFS’s Use of Credentials</a></p></li>
</ul>
</nav>
<section id="overview">
<h2><a class="toc-backref" href="#id1" role="doc-backlink">Overview</a><a class="headerlink" href="#overview" title="Link to this heading">¶</a></h2>
<p>There are several parts to the security check performed by Linux when one
object acts upon another:</p>
<blockquote>
<div><ol class="arabic">
<li><p>Objects.</p>
<blockquote>
<div><p>Objects are things in the system that may be acted upon directly by
userspace programs. Linux has a variety of actionable objects, including:</p>
<blockquote>
<div><ul class="simple">
<li><p>Tasks</p></li>
<li><p>Files/inodes</p></li>
<li><p>Sockets</p></li>
<li><p>Message queues</p></li>
<li><p>Shared memory segments</p></li>
<li><p>Semaphores</p></li>
<li><p>Keys</p></li>
</ul>
</div></blockquote>
<p>As a part of the description of all these objects there is a set of
credentials. What’s in the set depends on the type of object.</p>
</div></blockquote>
</li>
<li><p>Object ownership.</p>
<blockquote>
<div><p>Amongst the credentials of most objects, there will be a subset that
indicates the ownership of that object. This is used for resource
accounting and limitation (disk quotas and task rlimits for example).</p>
<p>In a standard UNIX filesystem, for instance, this will be defined by the
UID marked on the inode.</p>
</div></blockquote>
</li>
<li><p>The objective context.</p>
<blockquote>
<div><p>Also amongst the credentials of those objects, there will be a subset that
indicates the ‘objective context’ of that object. This may or may not be
the same set as in (2) - in standard UNIX files, for instance, this is the
defined by the UID and the GID marked on the inode.</p>
<p>The objective context is used as part of the security calculation that is
carried out when an object is acted upon.</p>
</div></blockquote>
</li>
<li><p>Subjects.</p>
<blockquote>
<div><p>A subject is an object that is acting upon another object.</p>
<p>Most of the objects in the system are inactive: they don’t act on other
objects within the system. Processes/tasks are the obvious exception:
they do stuff; they access and manipulate things.</p>
<p>Objects other than tasks may under some circumstances also be subjects.
For instance an open file may send SIGIO to a task using the UID and EUID
given to it by a task that called <code class="docutils literal notranslate"><span class="pre">fcntl(F_SETOWN)</span></code> upon it. In this case,
the file <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">will</span></code> have a subjective context too.</p>
</div></blockquote>
</li>
<li><p>The subjective context.</p>
<blockquote>
<div><p>A subject has an additional interpretation of its credentials. A subset
of its credentials forms the ‘subjective context’. The subjective context
is used as part of the security calculation that is carried out when a
subject acts.</p>
<p>A Linux task, for example, has the FSUID, FSGID and the supplementary
group list for when it is acting upon a file - which are quite separate
from the real UID and GID that normally form the objective context of the
task.</p>
</div></blockquote>
</li>
<li><p>Actions.</p>
<blockquote>
<div><p>Linux has a number of actions available that a subject may perform upon an
object. The set of actions available depends on the nature of the subject
and the object.</p>
<p>Actions include reading, writing, creating and deleting files; forking or
signalling and tracing tasks.</p>
</div></blockquote>
</li>
<li><p>Rules, access control lists and security calculations.</p>
<blockquote>
<div><p>When a subject acts upon an object, a security calculation is made. This
involves taking the subjective context, the objective context and the
action, and searching one or more sets of rules to see whether the subject
is granted or denied permission to act in the desired manner on the
object, given those contexts.</p>
<p>There are two main sources of rules:</p>
<ol class="loweralpha">
<li><p>Discretionary access control (DAC):</p>
<blockquote>
<div><p>Sometimes the object will include sets of rules as part of its
description. This is an ‘Access Control List’ or ‘ACL’. A Linux
file may supply more than one ACL.</p>
<p>A traditional UNIX file, for example, includes a permissions mask that
is an abbreviated ACL with three fixed classes of subject (‘user’,
‘group’ and ‘other’), each of which may be granted certain privileges
(‘read’, ‘write’ and ‘execute’ - whatever those map to for the object
in question). UNIX file permissions do not allow the arbitrary
specification of subjects, however, and so are of limited use.</p>
<p>A Linux file might also sport a POSIX ACL. This is a list of rules
that grants various permissions to arbitrary subjects.</p>
</div></blockquote>
</li>
<li><p>Mandatory access control (MAC):</p>
<blockquote>
<div><p>The system as a whole may have one or more sets of rules that get
applied to all subjects and objects, regardless of their source.
SELinux and Smack are examples of this.</p>
<p>In the case of SELinux and Smack, each object is given a label as part
of its credentials. When an action is requested, they take the
subject label, the object label and the action and look for a rule
that says that this action is either granted or denied.</p>
</div></blockquote>
</li>
</ol>
</div></blockquote>
</li>
</ol>
</div></blockquote>
</section>
<section id="types-of-credentials">
<h2><a class="toc-backref" href="#id2" role="doc-backlink">Types of Credentials</a><a class="headerlink" href="#types-of-credentials" title="Link to this heading">¶</a></h2>
<p>The Linux kernel supports the following types of credentials:</p>
<blockquote>
<div><ol class="arabic">
<li><p>Traditional UNIX credentials.</p>
<blockquote>
<div><blockquote>
<div><ul class="simple">
<li><p>Real User ID</p></li>
<li><p>Real Group ID</p></li>
</ul>
</div></blockquote>
<p>The UID and GID are carried by most, if not all, Linux objects, even if in
some cases it has to be invented (FAT or CIFS files for example, which are
derived from Windows). These (mostly) define the objective context of
that object, with tasks being slightly different in some cases.</p>
<blockquote>
<div><ul class="simple">
<li><p>Effective, Saved and FS User ID</p></li>
<li><p>Effective, Saved and FS Group ID</p></li>
<li><p>Supplementary groups</p></li>
</ul>
</div></blockquote>
<p>These are additional credentials used by tasks only. Usually, an
EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID
will be used as the objective. For tasks, it should be noted that this is
not always true.</p>
</div></blockquote>
</li>
<li><p>Capabilities.</p>
<blockquote>
<div><blockquote>
<div><ul class="simple">
<li><p>Set of permitted capabilities</p></li>
<li><p>Set of inheritable capabilities</p></li>
<li><p>Set of effective capabilities</p></li>
<li><p>Capability bounding set</p></li>
</ul>
</div></blockquote>
<p>These are only carried by tasks. They indicate superior capabilities
granted piecemeal to a task that an ordinary task wouldn’t otherwise have.
These are manipulated implicitly by changes to the traditional UNIX
credentials, but can also be manipulated directly by the <code class="docutils literal notranslate"><span class="pre">capset()</span></code>
system call.</p>
<p>The permitted capabilities are those caps that the process might grant
itself to its effective or permitted sets through <code class="docutils literal notranslate"><span class="pre">capset()</span></code>. This
inheritable set might also be so constrained.</p>
<p>The effective capabilities are the ones that a task is actually allowed to
make use of itself.</p>
<p>The inheritable capabilities are the ones that may get passed across
<code class="docutils literal notranslate"><span class="pre">execve()</span></code>.</p>
<p>The bounding set limits the capabilities that may be inherited across
<code class="docutils literal notranslate"><span class="pre">execve()</span></code>, especially when a binary is executed that will execute as
UID 0.</p>
</div></blockquote>
</li>
<li><p>Secure management flags (securebits).</p>
<blockquote>
<div><p>These are only carried by tasks. These govern the way the above
credentials are manipulated and inherited over certain operations such as
execve(). They aren’t used directly as objective or subjective
credentials.</p>
</div></blockquote>
</li>
<li><p>Keys and keyrings.</p>
<blockquote>
<div><p>These are only carried by tasks. They carry and cache security tokens
that don’t fit into the other standard UNIX credentials. They are for
making such things as network filesystem keys available to the file
accesses performed by processes, without the necessity of ordinary
programs having to know about security details involved.</p>
<p>Keyrings are a special type of key. They carry sets of other keys and can
be searched for the desired key. Each process may subscribe to a number
of keyrings:</p>
<blockquote>
<div><p>Per-thread keying
Per-process keyring
Per-session keyring</p>
</div></blockquote>
<p>When a process accesses a key, if not already present, it will normally be
cached on one of these keyrings for future accesses to find.</p>
<p>For more information on using keys, see <code class="docutils literal notranslate"><span class="pre">Documentation/security/keys/*</span></code>.</p>
</div></blockquote>
</li>
<li><p>LSM</p>
<blockquote>
<div><p>The Linux Security Module allows extra controls to be placed over the
operations that a task may do. Currently Linux supports several LSM
options.</p>
<p>Some work by labelling the objects in a system and then applying sets of
rules (policies) that say what operations a task with one label may do to
an object with another label.</p>
</div></blockquote>
</li>
<li><p>AF_KEY</p>
<blockquote>
<div><p>This is a socket-based approach to credential management for networking
stacks [RFC 2367]. It isn’t discussed by this document as it doesn’t
interact directly with task and file credentials; rather it keeps system
level credentials.</p>
</div></blockquote>
</li>
</ol>
</div></blockquote>
<p>When a file is opened, part of the opening task’s subjective context is
recorded in the file <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">created</span></code>. This allows operations using that file
<code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">to</span></code> use those credentials instead of the subjective context of the task
that issued the operation. An example of this would be a file opened on a
network filesystem where the credentials of the opened file should be presented
to the server, regardless of who is actually doing a read or a write upon it.</p>
</section>
<section id="file-markings">
<h2><a class="toc-backref" href="#id3" role="doc-backlink">File Markings</a><a class="headerlink" href="#file-markings" title="Link to this heading">¶</a></h2>
<p>Files on disk or obtained over the network may have annotations that form the
objective security context of that file. Depending on the type of filesystem,
this may include one or more of the following:</p>
<blockquote>
<div><ul class="simple">
<li><p>UNIX UID, GID, mode;</p></li>
<li><p>Windows user ID;</p></li>
<li><p>Access control list;</p></li>
<li><p>LSM security label;</p></li>
<li><p>UNIX exec privilege escalation bits (SUID/SGID);</p></li>
<li><p>File capabilities exec privilege escalation bits.</p></li>
</ul>
</div></blockquote>
<p>These are compared to the task’s subjective security context, and certain
operations allowed or disallowed as a result. In the case of execve(), the
privilege escalation bits come into play, and may allow the resulting process
extra privileges, based on the annotations on the executable file.</p>
</section>
<section id="task-credentials">
<h2><a class="toc-backref" href="#id4" role="doc-backlink">Task Credentials</a><a class="headerlink" href="#task-credentials" title="Link to this heading">¶</a></h2>
<p>In Linux, all of a task’s credentials are held in (uid, gid) or through
(groups, keys, LSM security) a refcounted structure of type ‘<code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">cred</span></code>’.
Each task points to its credentials by a pointer called ‘cred’ in its
task_struct.</p>
<p>Once a set of credentials has been prepared and committed, it may not be
changed, barring the following exceptions:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p>its reference count may be changed;</p></li>
<li><p>the reference count on the group_info <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">it</span></code> points to may be changed;</p></li>
<li><p>the reference count on the security data it points to may be changed;</p></li>
<li><p>the reference count on any keyrings it points to may be changed;</p></li>
<li><p>any keyrings it points to may be revoked, expired or have their security
attributes changed; and</p></li>
<li><p>the contents of any keyrings to which it points may be changed (the whole
point of keyrings being a shared set of credentials, modifiable by anyone
with appropriate access).</p></li>
</ol>
</div></blockquote>
<p>To alter anything in the cred struct, the copy-and-replace principle must be
adhered to. First take a copy, then alter the copy and then use RCU to change
the task pointer to make it point to the new copy. There are wrappers to aid
with this (see below).</p>
<p>A task may only alter its _own_ credentials; it is no longer permitted for a
task to alter another’s credentials. This means the <code class="docutils literal notranslate"><span class="pre">capset()</span></code> system call
is no longer permitted to take any PID other than the one of the current
process. Also <code class="docutils literal notranslate"><span class="pre">keyctl_instantiate()</span></code> and <code class="docutils literal notranslate"><span class="pre">keyctl_negate()</span></code> functions no
longer permit attachment to process-specific keyrings in the requesting
process as the instantiating process may need to create them.</p>
<section id="immutable-credentials">
<h3><a class="toc-backref" href="#id5" role="doc-backlink">Immutable Credentials</a><a class="headerlink" href="#immutable-credentials" title="Link to this heading">¶</a></h3>
<p>Once a set of credentials has been made public (by calling <code class="docutils literal notranslate"><span class="pre">commit_creds()</span></code>
for example), it must be considered immutable, barring two exceptions:</p>
<blockquote>
<div><ol class="arabic simple">
<li><p>The reference count may be altered.</p></li>
<li><p>While the keyring subscriptions of a set of credentials may not be
changed, the keyrings subscribed to may have their contents altered.</p></li>
</ol>
</div></blockquote>
<p>To catch accidental credential alteration at compile time, <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">task_struct</span></code>
has _const_ pointers to its credential sets, as does <a class="reference internal" href="../filesystems/api-summary.html#c.file" title="file"><code class="xref c c-struct docutils literal notranslate"><span class="pre">struct</span> <span class="pre">file</span></code></a>. Furthermore,
certain functions such as <code class="docutils literal notranslate"><span class="pre">get_cred()</span></code> and <code class="docutils literal notranslate"><span class="pre">put_cred()</span></code> operate on const
pointers, thus rendering casts unnecessary, but require to temporarily ditch
the const qualification to be able to alter the reference count.</p>
</section>
<section id="accessing-task-credentials">
<h3><a class="toc-backref" href="#id6" role="doc-backlink">Accessing Task Credentials</a><a class="headerlink" href="#accessing-task-credentials" title="Link to this heading">¶</a></h3>
<p>A task being able to alter only its own credentials permits the current process
to read or replace its own credentials without the need for any form of locking
-- which simplifies things greatly. It can just call:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>const struct cred *current_cred()
</pre></div>
</div>
<p>to get a pointer to its credentials structure, and it doesn’t have to release
it afterwards.</p>
<p>There are convenience wrappers for retrieving specific aspects of a task’s
credentials (the value is simply returned in each case):</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>uid_t current_uid(void) Current's real UID
gid_t current_gid(void) Current's real GID
uid_t current_euid(void) Current's effective UID
gid_t current_egid(void) Current's effective GID
uid_t current_fsuid(void) Current's file access UID
gid_t current_fsgid(void) Current's file access GID
kernel_cap_t current_cap(void) Current's effective capabilities
struct user_struct *current_user(void) Current's user account
</pre></div>
</div>
<p>There are also convenience wrappers for retrieving specific associated pairs of
a task’s credentials:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>void current_uid_gid(uid_t *, gid_t *);
void current_euid_egid(uid_t *, gid_t *);
void current_fsuid_fsgid(uid_t *, gid_t *);
</pre></div>
</div>
<p>which return these pairs of values through their arguments after retrieving
them from the current task’s credentials.</p>
<p>In addition, there is a function for obtaining a reference on the current
process’s current set of credentials:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>const struct cred *get_current_cred(void);
</pre></div>
</div>
<p>and functions for getting references to one of the credentials that don’t
actually live in <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">cred</span></code>:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>struct user_struct *get_current_user(void);
struct group_info *get_current_groups(void);
</pre></div>
</div>
<p>which get references to the current process’s user accounting structure and
supplementary groups list respectively.</p>
<p>Once a reference has been obtained, it must be released with <code class="docutils literal notranslate"><span class="pre">put_cred()</span></code>,
<code class="docutils literal notranslate"><span class="pre">free_uid()</span></code> or <code class="docutils literal notranslate"><span class="pre">put_group_info()</span></code> as appropriate.</p>
</section>
<section id="accessing-another-task-s-credentials">
<h3><a class="toc-backref" href="#id7" role="doc-backlink">Accessing Another Task’s Credentials</a><a class="headerlink" href="#accessing-another-task-s-credentials" title="Link to this heading">¶</a></h3>
<p>While a task may access its own credentials without the need for locking, the
same is not true of a task wanting to access another task’s credentials. It
must use the RCU read lock and <code class="docutils literal notranslate"><span class="pre">rcu_dereference()</span></code>.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">rcu_dereference()</span></code> is wrapped by:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>const struct cred *__task_cred(struct task_struct *task);
</pre></div>
</div>
<p>This should be used inside the RCU read lock, as in the following example:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>void foo(struct task_struct *t, struct foo_data *f)
{
const struct cred *tcred;
...
rcu_read_lock();
tcred = __task_cred(t);
f->uid = tcred->uid;
f->gid = tcred->gid;
f->groups = get_group_info(tcred->groups);
rcu_read_unlock();
...
}
</pre></div>
</div>
<p>Should it be necessary to hold another task’s credentials for a long period of
time, and possibly to sleep while doing so, then the caller should get a
reference on them using:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>const struct cred *get_task_cred(struct task_struct *task);
</pre></div>
</div>
<p>This does all the RCU magic inside of it. The caller must call <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">put_cred()</span></code> on
the credentials so obtained when they’re finished with.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>The result of <code class="docutils literal notranslate"><span class="pre">__task_cred()</span></code> should not be passed directly to
<code class="docutils literal notranslate"><span class="pre">get_cred()</span></code> as this may race with <code class="docutils literal notranslate"><span class="pre">commit_cred()</span></code>.</p>
</div>
<p>There are a couple of convenience functions to access bits of another task’s
credentials, hiding the RCU magic from the caller:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>uid_t task_uid(task) Task's real UID
uid_t task_euid(task) Task's effective UID
</pre></div>
</div>
<p>If the caller is holding the RCU read lock at the time anyway, then:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>__task_cred(task)->uid
__task_cred(task)->euid
</pre></div>
</div>
<p>should be used instead. Similarly, if multiple aspects of a task’s credentials
need to be accessed, RCU read lock should be used, <code class="docutils literal notranslate"><span class="pre">__task_cred()</span></code> called,
the result stored in a temporary pointer and then the credential aspects called
from that before dropping the lock. This prevents the potentially expensive
RCU magic from being invoked multiple times.</p>
<p>Should some other single aspect of another task’s credentials need to be
accessed, then this can be used:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>task_cred_xxx(task, member)
</pre></div>
</div>
<p>where ‘member’ is a non-pointer member of the cred struct. For instance:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>uid_t task_cred_xxx(task, suid);
</pre></div>
</div>
<p>will retrieve ‘<code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">cred</span></code>::suid’ from the task, doing the appropriate RCU
magic. This may not be used for pointer members as what they point to may
disappear the moment the RCU read lock is dropped.</p>
</section>
<section id="altering-credentials">
<h3><a class="toc-backref" href="#id8" role="doc-backlink">Altering Credentials</a><a class="headerlink" href="#altering-credentials" title="Link to this heading">¶</a></h3>
<p>As previously mentioned, a task may only alter its own credentials, and may not
alter those of another task. This means that it doesn’t need to use any
locking to alter its own credentials.</p>
<p>To alter the current process’s credentials, a function should first prepare a
new set of credentials by calling:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>struct cred *prepare_creds(void);
</pre></div>
</div>
<p>this locks current->cred_replace_mutex and then allocates and constructs a
duplicate of the current process’s credentials, returning with the mutex still
held if successful. It returns NULL if not successful (out of memory).</p>
<p>The mutex prevents <code class="docutils literal notranslate"><span class="pre">ptrace()</span></code> from altering the ptrace state of a process
while security checks on credentials construction and changing is taking place
as the ptrace state may alter the outcome, particularly in the case of
<code class="docutils literal notranslate"><span class="pre">execve()</span></code>.</p>
<p>The new credentials set should be altered appropriately, and any security
checks and hooks done. Both the current and the proposed sets of credentials
are available for this purpose as <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">current_cred()</span></code> will return the current set
still at this point.</p>
<p>When replacing the group list, the new list must be sorted before it
is added to the credential, as a binary search is used to test for
membership. In practice, this means <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">groups_sort()</span></code> should be
called before <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">set_groups()</span></code> or <code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">set_current_groups()</span></code>.
<code class="xref c c-func broken_xref docutils literal notranslate"><span class="pre">groups_sort()</span></code> must not be called on a <code class="docutils literal notranslate"><span class="pre">struct</span> <span class="pre">group_list</span></code> which
is shared as it may permute elements as part of the sorting process
even if the array is already sorted.</p>
<p>When the credential set is ready, it should be committed to the current process
by calling:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>int commit_creds(struct cred *new);
</pre></div>
</div>
<p>This will alter various aspects of the credentials and the process, giving the
LSM a chance to do likewise, then it will use <code class="docutils literal notranslate"><span class="pre">rcu_assign_pointer()</span></code> to
actually commit the new credentials to <code class="docutils literal notranslate"><span class="pre">current->cred</span></code>, it will release
<code class="docutils literal notranslate"><span class="pre">current->cred_replace_mutex</span></code> to allow <code class="docutils literal notranslate"><span class="pre">ptrace()</span></code> to take place, and it
will notify the scheduler and others of the changes.</p>
<p>This function is guaranteed to return 0, so that it can be tail-called at the
end of such functions as <code class="docutils literal notranslate"><span class="pre">sys_setresuid()</span></code>.</p>
<p>Note that this function consumes the caller’s reference to the new credentials.
The caller should _not_ call <code class="docutils literal notranslate"><span class="pre">put_cred()</span></code> on the new credentials afterwards.</p>
<p>Furthermore, once this function has been called on a new set of credentials,
those credentials may _not_ be changed further.</p>
<p>Should the security checks fail or some other error occur after
<code class="docutils literal notranslate"><span class="pre">prepare_creds()</span></code> has been called, then the following function should be
invoked:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>void abort_creds(struct cred *new);
</pre></div>
</div>
<p>This releases the lock on <code class="docutils literal notranslate"><span class="pre">current->cred_replace_mutex</span></code> that
<code class="docutils literal notranslate"><span class="pre">prepare_creds()</span></code> got and then releases the new credentials.</p>
<p>A typical credentials alteration function would look something like this:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>int alter_suid(uid_t suid)
{
struct cred *new;
int ret;
new = prepare_creds();
if (!new)
return -ENOMEM;
new->suid = suid;
ret = security_alter_suid(new);
if (ret < 0) {
abort_creds(new);
return ret;
}
return commit_creds(new);
}
</pre></div>
</div>
</section>
<section id="managing-credentials">
<h3><a class="toc-backref" href="#id9" role="doc-backlink">Managing Credentials</a><a class="headerlink" href="#managing-credentials" title="Link to this heading">¶</a></h3>
<p>There are some functions to help manage credentials:</p>
<blockquote>
<div><ul>
<li><p><code class="docutils literal notranslate"><span class="pre">void</span> <span class="pre">put_cred(const</span> <span class="pre">struct</span> <span class="pre">cred</span> <span class="pre">*cred);</span></code></p>
<blockquote>
<div><p>This releases a reference to the given set of credentials. If the
reference count reaches zero, the credentials will be scheduled for
destruction by the RCU system.</p>
</div></blockquote>
</li>
<li><p><code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">struct</span> <span class="pre">cred</span> <span class="pre">*get_cred(const</span> <span class="pre">struct</span> <span class="pre">cred</span> <span class="pre">*cred);</span></code></p>
<blockquote>
<div><p>This gets a reference on a live set of credentials, returning a pointer to
that set of credentials.</p>
</div></blockquote>
</li>
</ul>
</div></blockquote>
</section>
</section>
<section id="open-file-credentials">
<h2><a class="toc-backref" href="#id10" role="doc-backlink">Open File Credentials</a><a class="headerlink" href="#open-file-credentials" title="Link to this heading">¶</a></h2>
<p>When a new file is opened, a reference is obtained on the opening task’s
credentials and this is attached to the file <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">as</span></code> <code class="docutils literal notranslate"><span class="pre">f_cred</span></code> in place of
<code class="docutils literal notranslate"><span class="pre">f_uid</span></code> and <code class="docutils literal notranslate"><span class="pre">f_gid</span></code>. Code that used to access <code class="docutils literal notranslate"><span class="pre">file->f_uid</span></code> and
<code class="docutils literal notranslate"><span class="pre">file->f_gid</span></code> should now access <code class="docutils literal notranslate"><span class="pre">file->f_cred->fsuid</span></code> and
<code class="docutils literal notranslate"><span class="pre">file->f_cred->fsgid</span></code>.</p>
<p>It is safe to access <code class="docutils literal notranslate"><span class="pre">f_cred</span></code> without the use of RCU or locking because the
pointer will not change over the lifetime of the file struct, and nor will the
contents of the cred <code class="xref c c-struct broken_xref docutils literal notranslate"><span class="pre">struct</span> <span class="pre">pointed</span></code> to, barring the exceptions listed above
(see the Task Credentials section).</p>
<p>To avoid “confused deputy” privilege escalation attacks, access control checks
during subsequent operations on an opened file should use these credentials
instead of “current“‘s credentials, as the file may have been passed to a more
privileged process.</p>
</section>
<section id="overriding-the-vfs-s-use-of-credentials">
<h2><a class="toc-backref" href="#id11" role="doc-backlink">Overriding the VFS’s Use of Credentials</a><a class="headerlink" href="#overriding-the-vfs-s-use-of-credentials" title="Link to this heading">¶</a></h2>
<p>Under some circumstances it is desirable to override the credentials used by
the VFS, and that can be done by calling into such as <code class="docutils literal notranslate"><span class="pre">vfs_mkdir()</span></code> with a
different set of credentials. This is done in the following places:</p>
<blockquote>
<div><ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">sys_faccessat()</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">vfs_coredump()</span></code>.</p></li>
<li><p>nfs4recover.c.</p></li>
</ul>
</div></blockquote>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/security/credentials.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>