• Home
  • Raw
  • Download

Lines Matching +full:documentation +full:- +full:service

2 Kernel Key Retention Service
5 This service allows cryptographic keys, authentication tokens, cross-domain
11 kernel service can search for relevant keys.
13 The key service can be configured on by enabling:
30 - A serial number.
31 - A type.
32 - A description (for matching a key in a search).
33 - Access control information.
34 - An expiry time.
35 - A payload.
36 - State.
40 the lifetime of that key. All serial numbers are positive non-zero 32-bit
47 kernel by a kernel service (such as a filesystem) before keys of that type
62 whether a kernel service will be able to find the key.
69 the keyring links; in the case of a user-defined key, it's an arbitrary
91 * Negative. This is a relatively short-lived state. The key acts as a
109 Key Service Overview
112 The key service provides a number of features besides keys:
114 * The key service defines three special key types:
134 The description can be arbitrary, but must be prefixed with a non-zero
140 * Each process subscribes to three keyrings: a thread-specific keyring, a
141 process-specific keyring, and a session-specific keyring.
143 The thread-specific keyring is discarded from the child when any sort of
147 The process-specific keyring is replaced with an empty one in the child on
152 The session-specific keyring is persistent across clone, fork, vfork and
153 execve, even when the latter executes a set-UID or set-GID binary. A
163 keyring is initialised with a link to the user-specific keyring.
179 Process-specific and thread-specific keyrings are not counted towards a
207 This permits a key or keyring's attributes to be viewed - including key
250 newly-created keys. If the contents of that file correspond to an SELinux
254 particular context to newly-created keys, using the "create" permission in the
275 about the status of the key service:
292 00000001 I----- 39 perm 1f3f0000 0 0 keyring _uid_ses.0: 1/4
293 00000002 I----- 2 perm 1f3f0000 0 0 keyring _uid.0: empty
294 00000007 I----- 1 perm 1f3f0000 0 0 keyring _pid.1: empty
295 0000018d I----- 1 perm 1f3f0000 0 0 keyring _pid.412: empty
296 000004d2 I--Q-- 1 perm 1f3f0000 32 -1 keyring _uid.32: 1/4
297 000004d3 I--Q-- 3 perm 1f3f0000 32 -1 keyring _uid_ses.32: empty
298 00000892 I--QU- 1 perm 1f000000 0 0 user metal:copper: 0
299 00000893 I--Q-N 1 35s 1f3f0000 0 0 user metal:silver: 0
300 00000894 I--Q-- 1 10h 003f0000 0 0 user metal:gold: 0
312 * /proc/key-users
317 [root@andromeda root]# cat /proc/key-users
345 These files hold the maximum number of keys that each non-root user may
361 serial number (a positive 32-bit integer). However, there are some special
367 KEY_SPEC_THREAD_KEYRING -1 thread-specific keyring
368 KEY_SPEC_PROCESS_KEYRING -2 process-specific keyring
369 KEY_SPEC_SESSION_KEYRING -3 session-specific keyring
370 KEY_SPEC_USER_KEYRING -4 UID-specific keyring
371 KEY_SPEC_USER_SESSION_KEYRING -5 UID-session keyring
372 KEY_SPEC_GROUP_KEYRING -6 GID-specific keyring
373 KEY_SPEC_REQKEY_AUTH_KEY -7 assumed request_key()
415 kernel service such as a filesystem.
433 /sbin/request-key will be invoked in an attempt to obtain a key. The
440 See also Documentation/security/keys/request-key.rst.
455 non-zero; and the error ENOKEY will be returned if "create" is zero.
504 of uid or gid can be set to -1 to suppress that change.
634 into the destination keyring if one is supplied (non-zero ID). All the
680 If a keyring is specified (non-zero), the key will also be linked into
704 If a keyring is specified (non-zero), the key will also be linked into
713 * Set the default request-key destination keyring::
722 KEY_REQKEY_DEFL_NO_CHANGE -1 No change
836 * Compute a Diffie-Hellman shared secret or public key::
843 - The prime, p, known to both parties
844 - The local private key
845 - The base integer, which is either a shared generator or the
858 - The buffer length must be at least the length of the prime, or zero.
860 - If the buffer length is nonzero, the length of the result is
866 (KDF) on the Diffie-Hellman computation where only the result
870 - ``char *hashname`` specifies the NUL terminated string identifying
872 operation. The KDF implementation complies with SP800-56A as well
873 as with SP800-108 (the counter KDF).
875 - ``char *otherinfo`` specifies the OtherInfo data as documented in
876 SP800-56A section 5.8.1.2. The length of the buffer is given with
883 function will return EMSGSIZE when the parameter kdf is non-NULL
915 See Documentation/crypto/asymmetric-keys.rst for specific restrictions
928 string containing a space- or tab-separated string of key-value pairs.
941 supported. This is constructed from a bitwise-OR of::
984 Use an asymmetric key to perform a public-key cryptographic operation a
1006 KEYCTL_PKEY_ENCRYPT Raw data Encrypted data -
1007 KEYCTL_PKEY_DECRYPT Encrypted data Raw data -
1008 KEYCTL_PKEY_SIGN Raw data Signature -
1009 KEYCTL_PKEY_VERIFY Raw data - Signature
1015 can be "pkcs1" for RSASSA-PKCS1-v1.5 or
1016 RSAES-PKCS1-v1.5; "pss" for "RSASSA-PSS"; "oaep" for
1017 "RSAES-OAEP". If omitted or is "raw", the raw output
1049 See Documentation/core-api/watch_queue.rst for more information.
1096 Dealing with keys is fairly straightforward. Firstly, the kernel service
1111 <keys/user-type.h>
1119 least four-byte aligned.
1153 not NULL, then /sbin/request-key will be invoked in an attempt to obtain
1161 implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
1163 See also Documentation/security/keys/request-key.rst.
1189 passed to the key_type->request_key() op if it exists, and the
1282 - provided they can be verified by a key the kernel already has.
1291 -EPERM to in this case.
1331 The simplest payload is just data stored in key->payload directly. In this
1335 key->payload.data[] array. One of the following ways must be selected to
1347 the payload pointer. It must be write-locked for modifications and would
1348 have to be read-locked for general access. The disadvantage of doing this
1371 the payload. key->datalen cannot be relied upon to be consistent with the
1374 Note that key->payload.data[0] has a shadow that is marked for __rcu
1375 usage. This is called key->payload.rcu_data0. The following accessors
1398 A kernel service may want to define its own key type. For instance, an AFS
1404 <linux/key-type.h>
1416 This is optional - it supplies the default payload data length as
1483 The prep->data and prep->datalen fields will define the original payload
1487 keytype->def_datalen, then key_payload_reserve() should be called.
1490 The fact that KEY_FLAG_INSTANTIATED is not set in key->flags prevents
1496 prep->payload.data[] to key->payload.data[], with RCU-safe assignment on
1497 the first element. It will then clear prep->payload.data[] so that the
1506 The prep->data and prep->datalen fields will define the original payload
1514 The key will have its semaphore write-locked before this method is called,
1546 * KEYRING_SEARCH_LOOKUP_DIRECT - A direct lookup hashes the type and
1549 * KEYRING_SEARCH_LOOKUP_ITERATE - An iterative lookup walks all the
1574 match_data->preparsed after a successful call to match_preparse().
1581 write-locked.
1606 accessed. key->datalen cannot be trusted to stay consistent with the
1625 This method will be called with the key's semaphore read-locked. This will
1634 invoke this function rather than upcalling to /sbin/request-key to operate
1649 The error parameter should be 0 on success, -ve on error. The
1676 attempted key link operation. If there is no match, -EINVAL is returned.
1707 RSASSA-PKCS1-v1.5 or RSAES-PKCS1-v1.5 encoding or "raw" if no encoding);
1717 kernel_pkey_encrypt Raw data Encrypted data -
1718 kernel_pkey_decrypt Encrypted data Raw data -
1719 kernel_pkey_sign Raw data Signature -
1720 kernel_pkey_verify Raw data - Signature
1723 specified by params->op. Note that params->op is also set for
1730 digest algorithm - the name of which should be supplied in hash_algo.
1789 Request-Key Callback Service
1795 /sbin/request-key create <key> <uid> <gid> \
1803 required to obtain the key, eg: a Kerberos Ticket-Granting Ticket.
1824 service. This will be passed as the <callout_info> parameter. If no such
1825 information was made available, then "-" will be passed as this parameter
1832 /sbin/request-key update <key> <uid> <gid> \