diff options
Diffstat (limited to 'man7/keyrings.7')
| -rw-r--r-- | man7/keyrings.7 | 86 |
1 files changed, 43 insertions, 43 deletions
diff --git a/man7/keyrings.7 b/man7/keyrings.7 index 1ebd25f..879d1aa 100644 --- a/man7/keyrings.7 +++ b/man7/keyrings.7 @@ -4,7 +4,7 @@ .\" .\" SPDX-License-Identifier: GPL-2.0-or-later .\" -.TH keyrings 7 2023-02-05 "Linux man-pages 6.05.01" +.TH keyrings 7 2024-02-25 "Linux man-pages 6.7" .SH NAME keyrings \- in-kernel key management and retention facility .SH DESCRIPTION @@ -12,14 +12,14 @@ 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. -.PP +.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 .BR add_key (2), .BR request_key (2), and .BR keyctl (2). -.PP +.P A library and some user-space utilities are provided to allow access to the facility. See @@ -98,7 +98,7 @@ the key is scheduled for garbage collection. .SS Key types The kernel provides several basic types of key: .TP -.I """keyring""" +.I \[dq]keyring\[dq] .\" Note that keyrings use different fields in struct key in order to store .\" their data - index_key instead of type/description and name_link/keys .\" instead of payload. @@ -111,7 +111,7 @@ being garbage collected because nothing refers to them. Keyrings with descriptions (names) that begin with a period (\[aq].\[aq]) are reserved to the implementation. .TP -.I """user""" +.I \[dq]user\[dq] 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. @@ -123,12 +123,12 @@ 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 -.IR """afs:mykey""" ). +.IR \[dq]afs:mykey\[dq] ). .TP -.IR """logon""" " (since Linux 3.3)" +.IR \[dq]logon\[dq] " (since Linux 3.3)" .\" commit 9f6ed2ca257fa8650b876377833e6f14e272848b This key type is essentially the same as -.IR """user""" , +.IR \[dq]user\[dq] , but it does not provide reading (i.e., the .BR keyctl (2) .B KEYCTL_READ @@ -138,19 +138,19 @@ This is suitable for storing username-password pairs that should not be readable from user space. .IP The description of a -.I """logon""" +.I \[dq]logon\[dq] key .I must 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 \[dq]user\[dq] type, where the inclusion of a prefix is recommended but is not enforced.) .TP -.IR """big_key""" " (since Linux 3.13)" +.IR \[dq]big_key\[dq] " (since Linux 3.13)" .\" commit ab3c3587f8cda9083209a61dbe3a4407d3cada10 This key type is similar to the -.I """user""" +.I \[dq]user\[dq] 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. .IP @@ -165,11 +165,11 @@ Since Linux 4.8, .\" commit 13100a72f40f5748a04017e0ab3df4cf27c809ef the payload data is encrypted when stored in tmpfs, thereby preventing it from being written unencrypted into swap space. -.PP +.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. -.PP +.P Key type names that begin with a period (\[aq].\[aq]) are reserved to the implementation. .\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" @@ -179,7 +179,7 @@ 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. -.PP +.P Various operations (system calls) may be applied only to keyrings: .TP Adding @@ -204,7 +204,7 @@ 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. -.PP +.P See .BR keyctl_clear (3), .BR keyctl_link (3), @@ -217,13 +217,13 @@ for more information. 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. -.PP +.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. -.PP +.P The kernel makes available a number of anchor keyrings. Note that some of these keyrings will be created only when first accessed. .TP @@ -302,7 +302,7 @@ encryption keys for module signature verification. .IP These special keyrings are usually closed to direct alteration by user space. -.PP +.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. @@ -335,16 +335,16 @@ If a process is upcalled from the kernel to instantiate a key (see .BR request_key (2)), then it also possesses the requester's keyrings as in rule (1) as if it were the requester. -.PP +.P Note that possession is not a fundamental property of a key, but must rather be calculated each time the key is needed. -.PP +.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. -.PP +.P When it creates the session keyring, .BR pam_keyinit (8) adds a link to the @@ -361,7 +361,7 @@ The ID of a group that is permitted to access the key A security label .IP \[bu] A permissions mask -.PP +.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. @@ -379,17 +379,17 @@ filesystem GID or one of the caller's supplementary group IDs. .I other The set specifies the rights granted if neither the key's user ID nor group ID matched. -.PP +.P The fourth set of rights is: .TP .I possessor The set specifies the rights granted if a key is determined to be possessed by the caller. -.PP +.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. -.PP +.P The set of rights that may be granted in each of the four masks is as follows: .TP @@ -421,14 +421,14 @@ doesn't require this permission. .I setattr 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. -.PP +.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 .BR keyctl_get_security (3). -.PP +.P See .BR keyctl_chown (3), .BR keyctl_describe (3), @@ -447,7 +447,7 @@ 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.) -.PP +.P The search algorithm works as follows: .IP (1) 5 The process keyrings are searched in the following order: the @@ -480,10 +480,10 @@ If no valid matching key is found, then the first noted error state is returned; otherwise, an .B ENOKEY error is returned. -.PP +.P It is also possible to search a specific keyring, in which case only steps (3) to (6) apply. -.PP +.P See .BR request_key (2) and @@ -498,18 +498,18 @@ will, if given a 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. -.PP +.P Typically, this will involve the kernel creating a new process that executes the .BR request\-key (8) program, which will then execute the appropriate handler based on its configuration. -.PP +.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. -.PP +.P See .BR request_key (2), .BR keyctl_assume_authority (3), @@ -685,16 +685,16 @@ field provides some further information about the key. The information that appears here depends on the key type, as follows: .RS .TP -.IR """user""" " and " """logon""" +.IR \[dq]user\[dq] " and " \[dq]logon\[dq] The size in bytes of the key payload (expressed in decimal). .TP -.I """keyring""" +.I \[dq]keyring\[dq] The number of keys linked to the keyring, or the string .I empty if there are no keys linked to the keyring. .TP -.I """big_key""" +.I \[dq]big_key\[dq] The payload size in bytes, followed either by the string .IR [file] , if the key payload exceeds the threshold that means that the @@ -707,7 +707,7 @@ indicating that the key is small enough to reside in kernel memory. .RE .IP For the -.I """.request_key_auth""" +.I \[dq].request_key_auth\[dq] key type (authorization key; see .BR request_key (2)), @@ -796,7 +796,7 @@ or the operation.) .IP The default value in this file is 259200 (i.e., 3 days). -.PP +.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: @@ -833,14 +833,14 @@ may own. .IP .\"738c5d190f6540539a04baf36ce21d46b5da04bd The default value in this file is 1,000,000 (200 before Linux 3.17). -.PP +.P With respect to keyrings, note that each link in a keyring consumes 4 bytes of the keyring payload. .\""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" .SS Users The Linux key-management facility has a number of users and usages, but is not limited to those that already exist. -.PP +.P In-kernel users of this facility include: .TP Network filesystems - DNS @@ -863,7 +863,7 @@ The CIFS filesystem uses keys to store passwords for accessing remote shares. Module verification The kernel build process can be made to cryptographically sign modules. That signature is then checked when a module is loaded. -.PP +.P User-space users of this facility include: .TP Kerberos key storage @@ -892,7 +892,7 @@ scripts can use them. .BR user\-session\-keyring (7), .BR pam_keyinit (8), .BR request\-key (8) -.PP +.P The kernel source files .I Documentation/crypto/asymmetric\-keys.txt and under |