1139 lines
34 KiB
HTML
1139 lines
34 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of KEYRINGS</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>KEYRINGS</H1>
|
|
Section: Linux Programmer's Manual (7)<BR>Updated: 2017-09-15<BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
keyrings - in-kernel key management and retention facility
|
|
<A NAME="lbAC"> </A>
|
|
<H2>DESCRIPTION</H2>
|
|
|
|
The Linux key-management facility
|
|
is primarily a way for various kernel components
|
|
to retain or cache security data,
|
|
authentication keys, encryption keys, and other data in the kernel.
|
|
<P>
|
|
|
|
System call interfaces are provided so that user-space programs can manage
|
|
those objects and also use the facility for their own purposes; see
|
|
<B><A HREF="/cgi-bin/man/man2html?2+add_key">add_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2).
|
|
|
|
<P>
|
|
|
|
A library and some user-space utilities are provided to allow access to the
|
|
facility.
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?1+keyctl">keyctl</A></B>(1),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl">keyctl</A></B>(3),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?7+keyutils">keyutils</A></B>(7)
|
|
|
|
for more information.
|
|
|
|
<A NAME="lbAD"> </A>
|
|
<H3>Keys</H3>
|
|
|
|
A key has the following attributes:
|
|
<DL COMPACT>
|
|
<DT id="1">Serial number (ID)<DD>
|
|
This is a unique integer handle by which a key is referred to in system calls.
|
|
The serial number is sometimes synonymously referred as the key ID.
|
|
Programmatically, key serial numbers are represented using the type
|
|
<I>key_serial_t</I>.
|
|
|
|
<DT id="2">Type<DD>
|
|
A key's type defines what sort of data can be held in the key,
|
|
how the proposed content of the key will be parsed,
|
|
and how the payload will be used.
|
|
<DT id="3"><DD>
|
|
There are a number of general-purpose types available, plus some specialist
|
|
types defined by specific kernel components.
|
|
<DT id="4">Description (name)<DD>
|
|
The key description is a printable string that is used as the search term
|
|
for the key (in conjunction with the key type) as well as a display name.
|
|
During searches, the description may be partially matched or exactly matched.
|
|
<DT id="5">Payload (data)<DD>
|
|
The payload is the actual content of a key.
|
|
This is usually set when a key is created,
|
|
but it is possible for the kernel to upcall to user space to finish the
|
|
instantiation of a key if that key wasn't already known to the kernel
|
|
when it was requested.
|
|
For further details, see
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2).
|
|
|
|
<DT id="6"><DD>
|
|
A key's payload can be read and updated if the key type supports it and if
|
|
suitable permission is granted to the caller.
|
|
<DT id="7">Access rights<DD>
|
|
Much as files do,
|
|
each key has an owning user ID, an owning group ID, and a security label.
|
|
Each key also has a set of permissions,
|
|
though there are more than for a normal UNIX file,
|
|
and there is an additional category---possessor---beyond the usual user,
|
|
group, and other (see
|
|
<I>Possession</I>,
|
|
|
|
below).
|
|
<DT id="8"><DD>
|
|
Note that keys are quota controlled, since they require unswappable kernel
|
|
memory.
|
|
The owning user ID specifies whose quota is to be debited.
|
|
<DT id="9">Expiration time<DD>
|
|
Each key can have an expiration time set.
|
|
When that time is reached,
|
|
the key is marked as being expired and accesses to it fail with the error
|
|
<B>EKEYEXPIRED</B>.
|
|
|
|
If not deleted, updated, or replaced, then, after a set amount of time,
|
|
an expired key is automatically removed (garbage collected)
|
|
along with all links to it,
|
|
and attempts to access the key fail with the error
|
|
<B>ENOKEY</B>.
|
|
|
|
<DT id="10">Reference count<DD>
|
|
Each key has a reference count.
|
|
Keys are referenced by keyrings, by currently active users,
|
|
and by a process's credentials.
|
|
When the reference count reaches zero,
|
|
the key is scheduled for garbage collection.
|
|
|
|
</DL>
|
|
<A NAME="lbAE"> </A>
|
|
<H3>Key types</H3>
|
|
|
|
The kernel provides several basic types of key:
|
|
<DL COMPACT>
|
|
<DT id="11"><I>keyring</I>
|
|
|
|
<DD>
|
|
|
|
|
|
|
|
Keyrings are special keys which store a set of links
|
|
to other keys (including other keyrings),
|
|
analogous to a directory holding links to files.
|
|
The main purpose of a keyring is to prevent other keys from
|
|
being garbage collected because nothing refers to them.
|
|
<DT id="12"><DD>
|
|
Keyrings with descriptions (names)
|
|
that begin with a period ('.') are reserved to the implementation.
|
|
<DT id="13"><I>user</I>
|
|
|
|
<DD>
|
|
This is a general-purpose key type.
|
|
The key is kept entirely within kernel memory.
|
|
The payload may be read and updated by user-space applications.
|
|
<DT id="14"><DD>
|
|
The payload for keys of this type is a blob of arbitrary data
|
|
of up to 32,767 bytes.
|
|
<DT id="15"><DD>
|
|
The description may be any valid string, though it is preferred that it
|
|
start with a colon-delimited prefix representing the service
|
|
to which the key is of interest
|
|
(for instance
|
|
<I>"afs:mykey"</I>).
|
|
|
|
<DT id="16"><I>"logon"</I> (since Linux 3.3)
|
|
|
|
<DD>
|
|
|
|
This key type is essentially the same as
|
|
<I>"user"</I>,
|
|
|
|
but it does not provide reading (i.e., the
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2)
|
|
|
|
<B>KEYCTL_READ</B>
|
|
|
|
operation),
|
|
meaning that the key payload is never visible from user space.
|
|
This is suitable for storing username-password pairs
|
|
that should not be readable from user space.
|
|
<DT id="17"><DD>
|
|
The description of a
|
|
<I>"logon"</I>
|
|
|
|
key
|
|
<I>must</I>
|
|
|
|
start with a non-empty colon-delimited prefix whose purpose
|
|
is to identify the service to which the key belongs.
|
|
(Note that this differs from keys of the
|
|
<I>"user"</I>
|
|
|
|
type, where the inclusion of a prefix is recommended but is not enforced.)
|
|
<DT id="18"><I>"big_key"</I> (since Linux 3.13)
|
|
|
|
<DD>
|
|
|
|
This key type is similar to the
|
|
<I>user</I>
|
|
|
|
key type, but it may hold a payload of up to 1 MiB in size.
|
|
This key type is useful for purposes such as holding Kerberos ticket caches.
|
|
<DT id="19"><DD>
|
|
The payload data may be stored in a tmpfs filesystem,
|
|
rather than in kernel memory,
|
|
if the data size exceeds the overhead of storing the data in the filesystem.
|
|
(Storing the data in a filesystem requires filesystem structures
|
|
to be allocated in the kernel.
|
|
The size of these structures determines the size threshold
|
|
above which the tmpfs storage method is used.)
|
|
Since Linux 4.8,
|
|
|
|
the payload data is encrypted when stored in tmpfs,
|
|
thereby preventing it from being written unencrypted into swap space.
|
|
</DL>
|
|
<P>
|
|
|
|
There are more specialized key types available also,
|
|
but they aren't discussed here
|
|
because they aren't intended for normal user-space use.
|
|
<P>
|
|
|
|
Key type names
|
|
that begin with a period ('.') are reserved to the implementation.
|
|
|
|
<A NAME="lbAF"> </A>
|
|
<H3>Keyrings</H3>
|
|
|
|
As previously mentioned, keyrings are a special type of key that contain
|
|
links to other keys (which may include other keyrings).
|
|
Keys may be linked to by multiple keyrings.
|
|
Keyrings may be considered as analogous to UNIX directories
|
|
where each directory contains a set of hard links to files.
|
|
<P>
|
|
|
|
Various operations (system calls) may be applied only to keyrings:
|
|
<DL COMPACT>
|
|
<DT id="20">Adding<DD>
|
|
A key may be added to a keyring by system calls that create keys.
|
|
This prevents the new key from being immediately deleted
|
|
when the system call releases its last reference to the key.
|
|
<DT id="21">Linking<DD>
|
|
A link may be added to a keyring pointing to a key that is already known,
|
|
provided this does not create a self-referential cycle.
|
|
<DT id="22">Unlinking<DD>
|
|
A link may be removed from a keyring.
|
|
When the last link to a key is removed,
|
|
that key will be scheduled for deletion by the garbage collector.
|
|
<DT id="23">Clearing<DD>
|
|
All the links may be removed from a keyring.
|
|
<DT id="24">Searching<DD>
|
|
A keyring may be considered the root of a tree or subtree in which keyrings
|
|
form the branches and non-keyrings the leaves.
|
|
This tree may be searched for a key matching
|
|
a particular type and description.
|
|
</DL>
|
|
<P>
|
|
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_clear">keyctl_clear</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_link">keyctl_link</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_search">keyctl_search</A></B>(3),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_unlink">keyctl_unlink</A></B>(3)
|
|
|
|
for more information.
|
|
|
|
<A NAME="lbAG"> </A>
|
|
<H3>Anchoring keys</H3>
|
|
|
|
To prevent a key from being garbage collected,
|
|
it must be anchored to keep its reference count elevated
|
|
when it is not in active use by the kernel.
|
|
<P>
|
|
|
|
Keyrings are used to anchor other keys:
|
|
each link is a reference on a key.
|
|
Note that keyrings themselves are just keys and
|
|
are also subject to the same anchoring requirement to prevent
|
|
them being garbage collected.
|
|
<P>
|
|
|
|
The kernel makes available a number of anchor keyrings.
|
|
Note that some of these keyrings will be created only when first accessed.
|
|
<DL COMPACT>
|
|
<DT id="25">Process keyrings<DD>
|
|
Process credentials themselves reference keyrings with specific semantics.
|
|
These keyrings are pinned as long as the set of credentials exists,
|
|
which is usually as long as the process exists.
|
|
<DT id="26"><DD>
|
|
There are three keyrings with different inheritance/sharing rules:
|
|
the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+session-keyring">session-keyring</A></B>(7)
|
|
|
|
(inherited and shared by all child processes),
|
|
the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+process-keyring">process-keyring</A></B>(7)
|
|
|
|
(shared by all threads in a process) and
|
|
the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+thread-keyring">thread-keyring</A></B>(7)
|
|
|
|
(specific to a particular thread).
|
|
<DT id="27"><DD>
|
|
As an alternative to using the actual keyring IDs,
|
|
in calls to
|
|
<B><A HREF="/cgi-bin/man/man2html?2+add_key">add_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2),
|
|
|
|
the special keyring values
|
|
<B>KEY_SPEC_SESSION_KEYRING</B>,
|
|
|
|
<B>KEY_SPEC_PROCESS_KEYRING</B>,
|
|
|
|
and
|
|
<B>KEY_SPEC_THREAD_KEYRING</B>
|
|
|
|
can be used to refer to the caller's own instances of these keyrings.
|
|
<DT id="28">User keyrings<DD>
|
|
Each UID known to the kernel has a record that contains two keyrings: the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-keyring">user-keyring</A></B>(7)
|
|
|
|
and the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-session-keyring">user-session-keyring</A></B>(7).
|
|
|
|
These exist for as long as the UID record in the kernel exists.
|
|
<DT id="29"><DD>
|
|
As an alternative to using the actual keyring IDs,
|
|
in calls to
|
|
<B><A HREF="/cgi-bin/man/man2html?2+add_key">add_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2),
|
|
|
|
the special keyring values
|
|
<B>KEY_SPEC_USER_KEYRING</B>
|
|
|
|
and
|
|
<B>KEY_SPEC_USER_SESSION_KEYRING</B>
|
|
|
|
can be used to refer to the caller's own instances of these keyrings.
|
|
<DT id="30"><DD>
|
|
A link to the user keyring is placed in a new session keyring by
|
|
<B><A HREF="/cgi-bin/man/man2html?8+pam_keyinit">pam_keyinit</A></B>(8)
|
|
|
|
when a new login session is initiated.
|
|
<DT id="31">Persistent keyrings<DD>
|
|
There is a
|
|
<B><A HREF="/cgi-bin/man/man2html?7+persistent-keyring">persistent-keyring</A></B>(7)
|
|
|
|
available to each UID known to the system.
|
|
It may persist beyond the life of the UID record previously mentioned,
|
|
but has an expiration time set such that it is automatically cleaned up
|
|
after a set time.
|
|
The persistent keyring permits, for example,
|
|
<B><A HREF="/cgi-bin/man/man2html?8+cron">cron</A></B>(8)
|
|
|
|
scripts to use credentials that are left in the persistent keyring after
|
|
the user logs out.
|
|
<DT id="32"><DD>
|
|
Note that the expiration time of the persistent keyring
|
|
is reset every time the persistent key is requested.
|
|
<DT id="33">Special keyrings<DD>
|
|
There are special keyrings owned by the kernel that can anchor keys
|
|
for special purposes.
|
|
An example of this is the <I>system keyring</I> used for holding
|
|
encryption keys for module signature verification.
|
|
<DT id="34"><DD>
|
|
These special keyrings are usually closed to direct alteration
|
|
by user space.
|
|
</DL>
|
|
<P>
|
|
|
|
An originally planned "group keyring",
|
|
for storing keys associated with each GID known to the kernel,
|
|
is not so far implemented, is unlikely to be implemented.
|
|
Nevertheless, the constant
|
|
<B>KEY_SPEC_GROUP_KEYRING</B>
|
|
|
|
has been defined for this keyring.
|
|
|
|
<A NAME="lbAH"> </A>
|
|
<H3>Possession</H3>
|
|
|
|
The concept of possession is important to understanding the keyrings
|
|
security model.
|
|
Whether a thread possesses a key is determined by the following rules:
|
|
<DL COMPACT>
|
|
<DT id="35">(1)<DD>
|
|
Any key or keyring that does not grant
|
|
<I>search</I>
|
|
|
|
permission to the caller is ignored in all the following rules.
|
|
<DT id="36">(2)<DD>
|
|
A thread possesses its
|
|
<B><A HREF="/cgi-bin/man/man2html?7+session-keyring">session-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+process-keyring">process-keyring</A></B>(7),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?7+thread-keyring">thread-keyring</A></B>(7)
|
|
|
|
directly because those keyrings are referred to by its credentials.
|
|
<DT id="37">(3)<DD>
|
|
If a keyring is possessed, then any key it links to is also possessed.
|
|
<DT id="38">(4)<DD>
|
|
If any key a keyring links to is itself a keyring, then rule (3) applies
|
|
recursively.
|
|
<DT id="39">(5)<DD>
|
|
If a process is upcalled from the kernel to instantiate a key (see
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)),
|
|
|
|
then it also possesses the requester's keyrings as in
|
|
rule (1) as if it were the requester.
|
|
</DL>
|
|
<P>
|
|
|
|
Note that possession is not a fundamental property of a key,
|
|
but must rather be calculated each time the key is needed.
|
|
<P>
|
|
|
|
Possession is designed to allow set-user-ID programs run from, say
|
|
a user's shell to access the user's keys.
|
|
Granting permissions to the key possessor while denying them
|
|
to the key owner and group allows the prevention of access to keys
|
|
on the basis of UID and GID matches.
|
|
<P>
|
|
|
|
When it creates the session keyring,
|
|
<B><A HREF="/cgi-bin/man/man2html?8+pam_keyinit">pam_keyinit</A></B>(8)
|
|
|
|
adds a link to the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-keyring">user-keyring</A></B>(7),
|
|
|
|
thus making the user keyring and anything it contains possessed by default.
|
|
|
|
<A NAME="lbAI"> </A>
|
|
<H3>Access rights</H3>
|
|
|
|
Each key has the following security-related attributes:
|
|
<DL COMPACT>
|
|
<DT id="40">*<DD>
|
|
The owning user ID
|
|
<DT id="41">*<DD>
|
|
The ID of a group that is permitted to access the key
|
|
<DT id="42">*<DD>
|
|
A security label
|
|
<DT id="43">*<DD>
|
|
A permissions mask
|
|
</DL>
|
|
<P>
|
|
|
|
The permissions mask contains four sets of rights.
|
|
The first three sets are mutually exclusive.
|
|
One and only one will be in force for a particular access check.
|
|
In order of descending priority, these three sets are:
|
|
<DL COMPACT>
|
|
<DT id="44"><I>user</I><DD>
|
|
The set specifies the rights granted
|
|
if the key's user ID matches the caller's filesystem user ID.
|
|
<DT id="45"><I>group</I><DD>
|
|
The set specifies the rights granted
|
|
if the user ID didn't match and the key's group ID matches the caller's
|
|
filesystem GID or one of the caller's supplementary group IDs.
|
|
<DT id="46"><I>other</I><DD>
|
|
The set specifies the rights granted
|
|
if neither the key's user ID nor group ID matched.
|
|
</DL>
|
|
<P>
|
|
|
|
The fourth set of rights is:
|
|
<DL COMPACT>
|
|
<DT id="47"><I>possessor</I><DD>
|
|
The set specifies the rights granted
|
|
if a key is determined to be possessed by the caller.
|
|
</DL>
|
|
<P>
|
|
|
|
The complete set of rights for a key is the union of whichever
|
|
of the first three sets is applicable plus the fourth set
|
|
if the key is possessed.
|
|
<P>
|
|
|
|
The set of rights that may be granted in each of the four masks
|
|
is as follows:
|
|
<DL COMPACT>
|
|
<DT id="48"><I>view</I>
|
|
|
|
<DD>
|
|
The attributes of the key may be read.
|
|
This includes the type,
|
|
description, and access rights (excluding the security label).
|
|
<DT id="49"><I>read</I>
|
|
|
|
<DD>
|
|
For a key: the payload of the key may be read.
|
|
For a keyring: the list of serial numbers (keys) to
|
|
which the keyring has links may be read.
|
|
<DT id="50"><I>write</I>
|
|
|
|
<DD>
|
|
The payload of the key may be updated and the key may be revoked.
|
|
For a keyring, links may be added to or removed from the keyring,
|
|
and the keyring may be cleared completely (all links are removed),
|
|
<DT id="51"><I>search</I>
|
|
|
|
<DD>
|
|
For a key (or a keyring): the key may be found by a search.
|
|
For a keyring: keys and keyrings that are linked to by the
|
|
keyring may be searched.
|
|
<DT id="52"><I>link</I>
|
|
|
|
<DD>
|
|
Links may be created from keyrings to the key.
|
|
The initial link to a key that is established when the key is created
|
|
doesn't require this permission.
|
|
<DT id="53"><I>setattr</I>
|
|
|
|
<DD>
|
|
The ownership details and security label of the key may be changed,
|
|
the key's expiration time may be set, and the key may be revoked.
|
|
</DL>
|
|
<P>
|
|
|
|
In addition to access rights, any active Linux Security Module (LSM) may
|
|
prevent access to a key if its policy so dictates.
|
|
A key may be given a
|
|
security label or other attribute by the LSM;
|
|
this label is retrievable via
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_get_security">keyctl_get_security</A></B>(3).
|
|
|
|
<P>
|
|
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_chown">keyctl_chown</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_describe">keyctl_describe</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_get_security">keyctl_get_security</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_setperm">keyctl_setperm</A></B>(3),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?8+selinux">selinux</A></B>(8)
|
|
|
|
for more information.
|
|
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>Searching for keys</H3>
|
|
|
|
One of the key features of the Linux key-management facility
|
|
is the ability to find a key that a process is retaining.
|
|
The
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)
|
|
|
|
system call is the primary point of
|
|
access for user-space applications to find a key.
|
|
(Internally, the kernel has something similar available
|
|
for use by internal components that make use of keys.)
|
|
<P>
|
|
|
|
The search algorithm works as follows:
|
|
<DL COMPACT>
|
|
<DT id="54">(1)<DD>
|
|
The process keyrings are searched in the following order: the thread
|
|
<B><A HREF="/cgi-bin/man/man2html?7+thread-keyring">thread-keyring</A></B>(7)
|
|
|
|
if it exists, the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+process-keyring">process-keyring</A></B>(7)
|
|
|
|
if it exists, and then either the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+session-keyring">session-keyring</A></B>(7)
|
|
|
|
if it exists or the
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-session-keyring">user-session-keyring</A></B>(7)
|
|
|
|
if that exists.
|
|
<DT id="55">(2)<DD>
|
|
If the caller was a process that was invoked by the
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)
|
|
|
|
upcall mechanism, then the keyrings of the original caller of
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)
|
|
|
|
will be searched as well.
|
|
<DT id="56">(3)<DD>
|
|
The search of a keyring tree is in breadth-first order:
|
|
each keyring is searched first for a match,
|
|
then the keyrings referred to by that keyring are searched.
|
|
<DT id="57">(4)<DD>
|
|
If a matching key is found that is valid,
|
|
then the search terminates and that key is returned.
|
|
<DT id="58">(5)<DD>
|
|
If a matching key is found that has an error state attached,
|
|
that error state is noted and the search continues.
|
|
<DT id="59">(6)<DD>
|
|
If no valid matching key is found,
|
|
then the first noted error state is returned; otherwise, an
|
|
<B>ENOKEY</B>
|
|
|
|
error is returned.
|
|
</DL>
|
|
<P>
|
|
|
|
It is also possible to search a specific keyring, in which case only steps
|
|
(3) to (6) apply.
|
|
<P>
|
|
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_search">keyctl_search</A></B>(3)
|
|
|
|
for more information.
|
|
|
|
<A NAME="lbAK"> </A>
|
|
<H3>On-demand key creation</H3>
|
|
|
|
If a key cannot be found,
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)
|
|
|
|
will, if given a
|
|
<I>callout_info</I>
|
|
|
|
argument, create a new key and then upcall to user space to
|
|
instantiate the key.
|
|
This allows keys to be created on an as-needed basis.
|
|
<P>
|
|
|
|
Typically,
|
|
this will involve the kernel creating a new process that executes the
|
|
<B><A HREF="/cgi-bin/man/man2html?8+request-key">request-key</A></B>(8)
|
|
|
|
program, which will then execute the appropriate handler based on its
|
|
configuration.
|
|
<P>
|
|
|
|
The handler is passed a special authorization key that allows it
|
|
and only it to instantiate the new key.
|
|
This is also used to permit searches performed by the
|
|
handler program to also search the requester's keyrings.
|
|
<P>
|
|
|
|
See
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_assume_authority">keyctl_assume_authority</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_instantiate">keyctl_instantiate</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_negate">keyctl_negate</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_reject">keyctl_reject</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+request-key">request-key</A></B>(8),
|
|
|
|
and
|
|
<B><A HREF="/cgi-bin/man/man2html?5+request-key.conf">request-key.conf</A></B>(5)
|
|
|
|
for more information.
|
|
|
|
<A NAME="lbAL"> </A>
|
|
<H3>/proc files</H3>
|
|
|
|
The kernel provides various
|
|
<I>/proc</I>
|
|
|
|
files that expose information about keys or define limits on key usage.
|
|
<DL COMPACT>
|
|
<DT id="60"><I>/proc/keys</I> (since Linux 2.6.10)
|
|
|
|
<DD>
|
|
This file exposes a list of the keys for which the reading thread has
|
|
<I>view</I>
|
|
|
|
permission, providing various information about each key.
|
|
The thread need not possess the key for it to be visible in this file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<DT id="61"><DD>
|
|
The only keys included in the list are those that grant
|
|
<I>view</I>
|
|
|
|
permission to the reading process
|
|
(regardless of whether or not it possesses them).
|
|
LSM security checks are still performed,
|
|
and may filter out further keys that the process is not authorized to view.
|
|
<DT id="62"><DD>
|
|
An example of the data that one might see in this file
|
|
(with the columns numbered for easy reference below)
|
|
is the following:
|
|
<DT id="63"><DD>
|
|
|
|
|
|
<BR> (1) (2) (3)(4) (5) (6) (7) (8) (9)
|
|
009a2028 I--Q--- 1 perm 3f010000 1000 1000 user krb_ccache:primary: 12
|
|
1806c4ba I--Q--- 1 perm 3f010000 1000 1000 keyring _pid: 2
|
|
25d3a08f I--Q--- 1 perm 1f3f0000 1000 65534 keyring _uid_ses.1000: 1
|
|
28576bd8 I--Q--- 3 perm 3f010000 1000 1000 keyring _krb: 1
|
|
2c546d21 I--Q--- 190 perm 3f030000 1000 1000 keyring _ses: 2
|
|
30a4e0be I------ 4 2d 1f030000 1000 65534 keyring _persistent.1000: 1
|
|
32100fab I--Q--- 4 perm 1f3f0000 1000 65534 keyring _uid.1000: 2
|
|
32a387ea I--Q--- 1 perm 3f010000 1000 1000 keyring _pid: 2
|
|
3ce56aea I--Q--- 5 perm 3f030000 1000 1000 keyring _ses: 1
|
|
|
|
|
|
<DT id="64"><DD>
|
|
The fields shown in each line of this file are as follows:
|
|
<DL COMPACT><DT id="65"><DD>
|
|
<DL COMPACT>
|
|
<DT id="66">ID (1)<DD>
|
|
The ID (serial number) of the key, expressed in hexadecimal.
|
|
<DT id="67">Flags (2)<DD>
|
|
A set of flags describing the state of the key:
|
|
<DL COMPACT><DT id="68"><DD>
|
|
<DL COMPACT>
|
|
<DT id="69">I<DD>
|
|
|
|
The key has been instantiated.
|
|
<DT id="70">R<DD>
|
|
|
|
The key has been revoked.
|
|
<DT id="71">D<DD>
|
|
|
|
The key is dead (i.e., the key type has been unregistered).
|
|
|
|
(A key may be briefly in this state during garbage collection.)
|
|
<DT id="72">Q<DD>
|
|
|
|
The key contributes to the user's quota.
|
|
<DT id="73">U<DD>
|
|
|
|
The key is under construction via a callback to user space;
|
|
see
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request-key">request-key</A></B>(2).
|
|
|
|
<DT id="74">N<DD>
|
|
|
|
The key is negatively instantiated.
|
|
<DT id="75">i<DD>
|
|
|
|
The key has been invalidated.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="76">Usage (3)<DD>
|
|
This is a count of the number of kernel credential
|
|
structures that are pinning the key
|
|
(approximately: the number of threads and open file references
|
|
that refer to this key).
|
|
<DT id="77">Timeout (4)<DD>
|
|
The amount of time until the key will expire,
|
|
expressed in human-readable form (weeks, days, hours, minutes, and seconds).
|
|
The string
|
|
<I>perm</I>
|
|
|
|
here means that the key is permanent (no timeout).
|
|
The string
|
|
<I>expd</I>
|
|
|
|
means that the key has already expired,
|
|
but has not yet been garbage collected.
|
|
<DT id="78">Permissions (5)<DD>
|
|
The key permissions, expressed as four hexadecimal bytes containing,
|
|
from left to right, the possessor, user, group, and other permissions.
|
|
Within each byte, the permission bits are as follows:
|
|
<DT id="79"><DD>
|
|
|
|
<DL COMPACT><DT id="80"><DD>
|
|
<DL COMPACT>
|
|
<DT id="81">0x01<DD>
|
|
<I>view</I>
|
|
|
|
<DT id="82">Ox02<DD>
|
|
<I>read</I>
|
|
|
|
<DT id="83">0x04<DD>
|
|
<I>write</I>
|
|
|
|
<DT id="84">0x08<DD>
|
|
<I>search</I>
|
|
|
|
<DT id="85">0x10<DD>
|
|
<I>link</I>
|
|
|
|
<DT id="86">0x20<DD>
|
|
<I>setattr</I>
|
|
|
|
</DL>
|
|
</DL>
|
|
|
|
|
|
<DT id="87">UID (6)<DD>
|
|
The user ID of the key owner.
|
|
<DT id="88">GID (7)<DD>
|
|
The group ID of the key.
|
|
The value -1 here means that the key has no group ID;
|
|
this can occur in certain circumstances for keys created by the kernel.
|
|
<DT id="89">Type (8)<DD>
|
|
The key type (user, keyring, etc.)
|
|
<DT id="90">Description (9)<DD>
|
|
The key description (name).
|
|
This field contains descriptive information about the key.
|
|
For most key types, it has the form
|
|
<DT id="91"><DD>
|
|
<BR> name[: extra-info]
|
|
<DT id="92"><DD>
|
|
The
|
|
<I>name</I>
|
|
|
|
subfield is the key's description (name).
|
|
The optional
|
|
<I>extra-info</I>
|
|
|
|
field provides some further information about the key.
|
|
The information that appears here depends on the key type, as follows:
|
|
<DL COMPACT><DT id="93"><DD>
|
|
<DL COMPACT>
|
|
<DT id="94"><I>"user"</I> and <I>"logon"</I>
|
|
|
|
<DD>
|
|
The size in bytes of the key payload (expressed in decimal).
|
|
<DT id="95"><I>"keyring"</I>
|
|
|
|
<DD>
|
|
The number of keys linked to the keyring,
|
|
or the string
|
|
<I>empty</I>
|
|
|
|
if there are no keys linked to the keyring.
|
|
<DT id="96"><I>"big_key"</I>
|
|
|
|
<DD>
|
|
The payload size in bytes, followed either by the string
|
|
<I>[file]</I>,
|
|
|
|
if the key payload exceeds the threshold that means that the
|
|
payload is stored in a (swappable)
|
|
<B><A HREF="/cgi-bin/man/man2html?5+tmpfs">tmpfs</A></B>(5)
|
|
|
|
filesystem,
|
|
or otherwise the string
|
|
<I>[buff]</I>,
|
|
|
|
indicating that the key is small enough to reside in kernel memory.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="97"><DD>
|
|
For the
|
|
<I>".request_key_auth"</I>
|
|
|
|
key type
|
|
(authorization key; see
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2)),
|
|
|
|
the description field has the form shown in the following example:
|
|
<DT id="98"><DD>
|
|
<BR> key:c9a9b19 pid:28880 ci:10
|
|
<DT id="99"><DD>
|
|
The three subfields are as follows:
|
|
<DL COMPACT><DT id="100"><DD>
|
|
<DL COMPACT>
|
|
<DT id="101"><I>key</I>
|
|
|
|
<DD>
|
|
The hexadecimal ID of the key being instantiated in the requesting program.
|
|
<DT id="102"><I>pid</I>
|
|
|
|
<DD>
|
|
The PID of the requesting program.
|
|
<DT id="103"><I>ci</I>
|
|
|
|
<DD>
|
|
The length of the callout data with which the requested key should
|
|
be instantiated
|
|
(i.e., the length of the payload associated with the authorization key).
|
|
</DL>
|
|
</DL>
|
|
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="104"><I>/proc/key-users</I> (since Linux 2.6.10)
|
|
|
|
<DD>
|
|
This file lists various information for each user ID that
|
|
has at least one key on the system.
|
|
An example of the data that one might see in this file is the following:
|
|
<DT id="105"><DD>
|
|
|
|
|
|
<BR> 0: 10 9/9 2/1000000 22/25000000
|
|
<BR> 42: 9 9/9 8/200 106/20000
|
|
1000: 11 11/11 10/200 271/20000
|
|
|
|
|
|
<DT id="106"><DD>
|
|
The fields shown in each line are as follows:
|
|
<DL COMPACT><DT id="107"><DD>
|
|
<DL COMPACT>
|
|
<DT id="108"><I>uid</I>
|
|
|
|
<DD>
|
|
The user ID.
|
|
<DT id="109"><I>usage</I>
|
|
|
|
<DD>
|
|
This is a kernel-internal usage count for the kernel structure
|
|
used to record key users.
|
|
<DT id="110"><I>nkeys</I>/<I>nikeys</I>
|
|
|
|
<DD>
|
|
The total number of keys owned by the user,
|
|
and the number of those keys that have been instantiated.
|
|
<DT id="111"><I>qnkeys</I>/<I>maxkeys</I>
|
|
|
|
<DD>
|
|
The number of keys owned by the user,
|
|
and the maximum number of keys that the user may own.
|
|
<DT id="112"><I>qnbytes</I>/<I>maxbytes</I>
|
|
|
|
<DD>
|
|
The number of bytes consumed in payloads of the keys owned by this user,
|
|
and the upper limit on the number of bytes in key payloads for that user.
|
|
</DL>
|
|
</DL>
|
|
|
|
<DT id="113"><I>/proc/sys/kernel/keys/gc_delay</I> (since Linux 2.6.32)
|
|
|
|
<DD>
|
|
|
|
The value in this file specifies the interval, in seconds,
|
|
after which revoked and expired keys will be garbage collected.
|
|
The purpose of having such an interval is so that there is a window
|
|
of time where user space can see an error (respectively
|
|
<B>EKEYREVOKED</B>
|
|
|
|
and
|
|
<B>EKEYEXPIRED</B>)
|
|
|
|
that indicates what happened to the key.
|
|
<DT id="114"><DD>
|
|
The default value in this file is 300 (i.e., 5 minutes).
|
|
<DT id="115"><I>/proc/sys/kernel/keys/persistent_keyring_expiry</I> (since Linux 3.13)
|
|
|
|
<DD>
|
|
|
|
This file defines an interval, in seconds,
|
|
to which the persistent keyring's expiration timer is reset
|
|
each time the keyring is accessed (via
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl_get_persistent">keyctl_get_persistent</A></B>(3)
|
|
|
|
or the
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2)
|
|
|
|
<B>KEYCTL_GET_PERSISTENT</B>
|
|
|
|
operation.)
|
|
<DT id="116"><DD>
|
|
The default value in this file is 259200 (i.e., 3 days).
|
|
</DL>
|
|
<P>
|
|
|
|
The following files (which are writable by privileged processes)
|
|
are used to enforce quotas on the number of keys
|
|
and number of bytes of data that can be stored in key payloads:
|
|
<DL COMPACT>
|
|
<DT id="117"><I>/proc/sys/kernel/keys/maxbytes</I> (since Linux 2.6.26)
|
|
|
|
<DD>
|
|
|
|
|
|
This is the maximum number of bytes of data that a nonroot user
|
|
can hold in the payloads of the keys owned by the user.
|
|
<DT id="118"><DD>
|
|
The default value in this file is 20,000.
|
|
<DT id="119"><I>/proc/sys/kernel/keys/maxkeys</I> (since Linux 2.6.26)
|
|
|
|
<DD>
|
|
|
|
|
|
This is the maximum number of keys that a nonroot user may own.
|
|
<DT id="120"><DD>
|
|
The default value in this file is 200.
|
|
<DT id="121"><I>/proc/sys/kernel/keys/root_maxbytes</I> (since Linux 2.6.26)
|
|
|
|
<DD>
|
|
This is the maximum number of bytes of data that the root user
|
|
(UID 0 in the root user namespace)
|
|
can hold in the payloads of the keys owned by root.
|
|
<DT id="122"><DD>
|
|
|
|
The default value in this file is 25,000,000 (20,000 before Linux 3.17).
|
|
|
|
<DT id="123"><I>/proc/sys/kernel/keys/root_maxkeys</I> (since Linux 2.6.26)
|
|
|
|
<DD>
|
|
|
|
This is the maximum number of keys that the root user
|
|
(UID 0 in the root user namespace)
|
|
may own.
|
|
<DT id="124"><DD>
|
|
|
|
The default value in this file is 1,000,000 (200 before Linux 3.17).
|
|
</DL>
|
|
<P>
|
|
|
|
With respect to keyrings,
|
|
note that each link in a keyring consumes 4 bytes of the keyring payload.
|
|
|
|
<A NAME="lbAM"> </A>
|
|
<H3>Users</H3>
|
|
|
|
The Linux key-management facility has a number of users and usages,
|
|
but is not limited to those that already exist.
|
|
<P>
|
|
|
|
In-kernel users of this facility include:
|
|
<DL COMPACT>
|
|
<DT id="125">Network filesystems - DNS<DD>
|
|
The kernel uses the upcall mechanism provided by the keys to upcall to
|
|
user space to do DNS lookups and then to cache the results.
|
|
<DT id="126">AF_RXRPC and kAFS - Authentication<DD>
|
|
The AF_RXRPC network protocol and the in-kernel AFS filesystem
|
|
use keys to store the ticket needed to do secured or encrypted traffic.
|
|
These are then looked up by
|
|
network operations on AF_RXRPC and filesystem operations on kAFS.
|
|
<DT id="127">NFS - User ID mapping<DD>
|
|
The NFS filesystem uses keys to store mappings of
|
|
foreign user IDs to local user IDs.
|
|
<DT id="128">CIFS - Password<DD>
|
|
The CIFS filesystem uses keys to store passwords for accessing remote shares.
|
|
<DT id="129">Module verification<DD>
|
|
The kernel build process can be made to cryptographically sign modules.
|
|
That signature is then checked when a module is loaded.
|
|
</DL>
|
|
<P>
|
|
|
|
User-space users of this facility include:
|
|
<DL COMPACT>
|
|
<DT id="130">Kerberos key storage<DD>
|
|
The MIT Kerberos 5 facility (libkrb5) can use keys to store authentication
|
|
tokens which can be made to be automatically cleaned up a set time after
|
|
the user last uses them,
|
|
but until then permits them to hang around after the user
|
|
has logged out so that
|
|
<B><A HREF="/cgi-bin/man/man2html?8+cron">cron</A></B>(8)
|
|
|
|
scripts can use them.
|
|
|
|
</DL>
|
|
<A NAME="lbAN"> </A>
|
|
<H2>SEE ALSO</H2>
|
|
|
|
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?1+keyctl">keyctl</A></B>(1),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+add_key">add_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+keyctl">keyctl</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?2+request_key">request_key</A></B>(2),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?3+keyctl">keyctl</A></B>(3),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+keyutils">keyutils</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+persistent-keyring">persistent-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+process-keyring">process-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+session-keyring">session-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+thread-keyring">thread-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-keyring">user-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?7+user-session-keyring">user-session-keyring</A></B>(7),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+pam_keyinit">pam_keyinit</A></B>(8),
|
|
|
|
<B><A HREF="/cgi-bin/man/man2html?8+request-key">request-key</A></B>(8)
|
|
|
|
<P>
|
|
|
|
The kernel source files
|
|
<I>Documentation/crypto/asymmetric-keys.txt</I>
|
|
|
|
and under
|
|
<I>Documentation/security/keys</I>
|
|
|
|
(or, before Linux 4.13, in the file
|
|
<I>Documentation/security/keys.txt</I>).
|
|
|
|
<A NAME="lbAO"> </A>
|
|
<H2>COLOPHON</H2>
|
|
|
|
This page is part of release 5.05 of the Linux
|
|
<I>man-pages</I>
|
|
|
|
project.
|
|
A description of the project,
|
|
information about reporting bugs,
|
|
and the latest version of this page,
|
|
can be found at
|
|
<A HREF="https://www.kernel.org/doc/man-pages/.">https://www.kernel.org/doc/man-pages/.</A>
|
|
<P>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="131"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="132"><A HREF="#lbAC">DESCRIPTION</A><DD>
|
|
<DL>
|
|
<DT id="133"><A HREF="#lbAD">Keys</A><DD>
|
|
<DT id="134"><A HREF="#lbAE">Key types</A><DD>
|
|
<DT id="135"><A HREF="#lbAF">Keyrings</A><DD>
|
|
<DT id="136"><A HREF="#lbAG">Anchoring keys</A><DD>
|
|
<DT id="137"><A HREF="#lbAH">Possession</A><DD>
|
|
<DT id="138"><A HREF="#lbAI">Access rights</A><DD>
|
|
<DT id="139"><A HREF="#lbAJ">Searching for keys</A><DD>
|
|
<DT id="140"><A HREF="#lbAK">On-demand key creation</A><DD>
|
|
<DT id="141"><A HREF="#lbAL">/proc files</A><DD>
|
|
<DT id="142"><A HREF="#lbAM">Users</A><DD>
|
|
</DL>
|
|
<DT id="143"><A HREF="#lbAN">SEE ALSO</A><DD>
|
|
<DT id="144"><A HREF="#lbAO">COLOPHON</A><DD>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:09 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|