Provided by: manpages-fr_4.27.0-1_all 
NOM
keyrings – Gestion interne au noyau de clés et mémorisation
DESCRIPTION
La fonction de gestion de clés de Linux est principalement un moyen pour divers composants du noyau de
mémoriser ou de mettre en cache des données de sécurité, des clés d’authentification, des clés de
chiffrement et d’autres données dans le noyau.
Les interfaces d’appel système sont fournies de façon à ce que les programmes en espace utilisateur
puissent gérer ces objets, et aussi en utiliser la fonctionnalité pour leurs propres besoins. Consultez
add_key(2), request_key(2) et keyctl(2).
Une bibliothèque et quelques utilitaires en espace utilisateur sont fournis pour autoriser l’accès à
cette fonctionnalité. Consultez keyctl(1), keyctl(3) et keyutils(7) pour davantage d’informations.
Clés
Une clé possède les attributs suivants :
Numéro de série (ID)
IL s’agit d’un entier unique par lequel une clé est référencée dans des appels système. Le numéro
de série est parfois appelé de manière synonyme l’identifiant de clé. En programmation, les
numéros de série sont représentés en utilisant le type key_serial_t.
Type Le type de clé précise quelle sorte de données sera gérée par la clé, de quelle manière le contenu
présenté par la clé sera analysé et comment la charge utile sera utilisée.
Un certain nombre de types génériques sont disponibles en plus de types spécialisés définis par
des composants particuliers du noyau.
Description (nom)
La description de la clé est une chaîne affichable qui est utilisée comme terme de recherche de la
clé (conjointement avec le type de la clé) ainsi que comme nom à afficher. Lors des recherches, la
description peut correspondre partiellement ou totalement.
Charge utile (données)
La charge utile est le contenu réel de la clé. Elle est habituellement définie au moment de la
création de la clé, mais il est possible qu’un appel montant (upcall) du noyau dans l’espace
utilisateur finisse l’instanciation de la clé si celle-ci n’était pas connue du noyau quand elle a
été demandée. Pour plus de détails, consultez request_key(2).
Une charge utile de clé peut être lue et mise à jour si le type de clé le gère et si les
permissions adéquates sont données à l’appelant.
Droits d’accès
De la même manière que pour les fichiers, chaque clé possède un ID utilisateur, un ID de groupe et
une étiquette de sécurité. Chaque clé possède aussi un ensemble de permissions, mais il en existe
plus que pour un fichier UNIX normal, et il existe une catégorie supplémentaire – possesseur — en
plus des utilisateur, groupe et autres. Consultez Possession, ci-dessous).
Il est à remarquer que les clés sont sujettes à un quota puisqu’elles nécessitent de la mémoire du
noyau non « swappable ». L’ID de l’utilisateur propriétaire indique quel quota doit être débité.
Heure d’expiration
Chaque clé peut avoir une heure d’expiration définie. Quand ce moment est atteint, la clé est
marquée comme périmée et une demande d’accès à celle-ci échouera avec l’erreur EKEYEXPIRED. Si
elle n’est pas supprimée, mise à jour ou remplacée, alors après un certain temps, la clé ayant
expirée est automatiquement supprimée (collectée par le ramasse-miettes) avec tous les liens vers
elle, et toute tentative d'accès à cette clé échouera avec l’erreur ENOKEY.
Comptage de références
Chaque clé possède un comptage de références. Les clés sont référencées par des trousseaux de
clés, par les utilisateurs actuellement actifs, et par les identifiants d'un processus. Quand le
comptage de références atteint zéro, la clé est programmée pour le ramasse-miettes.
Types de clé
Le noyau fournit plusieurs types basiques de clé :
"keyring"
Les trousseaux de clés sont des clés spéciales qui stockent un ensemble de liens vers d’autres
clés (incluant d’autres trousseaux de clés), de manière analogue à un répertoire contenant des
liens vers des fichiers. L’objectif principal d’un trousseau de clés est d’empêcher d’autres clés
d’être collectées par le ramasse-miettes parce qu’elles ne servent de références à rien.
Les trousseaux de clés avec des descriptions (noms) commençant par un point (.) sont réservées à
l’implémentation.
"user" Il s’agit d’un type de clé générique. La clé est entièrement conservée dans la mémoire du noyau.
La charge utile peut être lue et mise à jour par des applications de l’espace utilisateur.
La charge utile des clés de ce type est un objet binaire (blob) de données arbitraires pouvant
contenir 32 767 octets.
La description peut être n’importe quelle chaîne autorisée, bien qu’il soit préférable qu’elle
commence par un préfixe délimité par un deux-points représentant le service auquel la clé est
destinée (par exemple, « afs:mykey »).
"logon" (depuis Linux 3.3)
Ce type de clé est fondamentalement identique à « user », mais ne permet pas la lecture
(c’est-à-dire l’opération KEYCTL_READ de keyctl(2)), signifiant que la charge utile n’est jamais
visible à partir de l’espace utilisateur. Cela est adapté au stockage de paires nom
d’utilisateur/mot de passe qui ne doivent pas être lisibles à partir de l’espace utilisateur.
La description de la clé « logon » doit débuter par un préfixe non vide délimité par un
deux-points dont le but est d’identifier le service auquel la clé appartient. Il est à remarquer
que cela diffère du type de clé « user » où l’incorporation du préfixe est recommandée mais pas
obligée.
"big_key" (depuis Linux 3.13)
Ce type de clé est semblable au type « user » de clé, mais il peut contenir une charge utile de
taille 1 MiB. Ce type de clé est utile pour, par exemple, contenir des caches de ticket Kerberos.
Les données de la charge utile peuvent être stockées dans un système de fichiers tmpfs, plutôt que
dans la mémoire du noyau si la taille des données excède la surcharge due au stockage des données
dans le système de fichiers. Stocker les données dans un système de fichiers nécessite que des
structures de système de fichiers soient allouées dans le noyau. La taille de ces structures
détermine le seuil au-dessus duquel la méthode tmpfs de stockage est utilisée. Depuis Linux 4.8,
les données de la charge utile sont chiffrées lorsqu’elles sont stockées en tmpfs, empêchant par
conséquentqu’elles soient écrites dans l’espace d’échange sans être chiffrées.
Il existe aussi d’autres types de clé spécialisés, mais ils ne sont pas évoqués ici, car ils ne sont pas
destinés à une utilisation normale en espace utilisateur.
Les noms de type de clé qui commencent par un point (.) sont réservés à l’implémentation.
Trousseaux de clés
Comme indiqué précédemment, les trousseaux de clés sont un type spécial de clé qui contient des liens
vers d’autres clés (pouvant inclure d’autres trousseaux de clés). Les clés peuvent être liées à plusieurs
trousseaux de clés. Les trousseaux de clés peuvent être considérés comme analogues à des répertoires UNIX
où chaque répertoire contient un ensemble de liens physiques vers des fichiers.
Différentes opérations (appels système) ne peuvent être appliquées qu’aux trousseaux de clés :
Ajout Une clé peut être ajoutée dans un trousseau de clés par les appels système ayant créé les clés.
Cela évite que la nouvelle clé soit détruite immédiatement quand l'appel système libère la
dernière référence à la clé.
Liaison
Un lien peut être ajouté à un trousseau de clés pointant vers une clé déjà connue, si cela ne crée
pas de cycle d’auto-référencement.
Déliaison
Un lien peut être supprimé d’un trousseau de clés. Quand le dernier lien vers une clé est
supprimé, cette clé sera programmée pour être collectée par le ramasse-miettes.
Effacement
Tous les liens peuvent être supprimés d’un trousseau de clés.
Recherche
Un trousseau de clés peut être considéré comme la racine d’un arbre ou d’un sous-arbre dans
lesquels les trousseaux de clés forment les branches et le reste les feuilles. Cet arbre peut être
parcouru pour rechercher une clé d’une description ou d’un type particulier.
Consultez keyctl_clear(3), keyctl_link(3), keyctl_search(3) et keyctl_unlink(3) pour davantage
d’informations.
Clés d’ancrage
Pour empêcher une clé d’être collectée par le ramasse-miettes, elle doit être ancrée pour conserver son
comptage de références en cours lorsqu’elle n’est pas utilisée activement par le noyau.
Les trousseaux de clés sont utilisés pour ancrer d’autres clés. Chaque lien est une référence à une clé.
Il est à remarquer que les trousseaux de clés sont eux-mêmes des clés et sont aussi sujets à la même
nécessité d’ancrage pour empêcher qu’ils soient collectés par le ramasse-miettes.
Le noyau propose un certain nombre de trousseaux de clés d’ancrage. Il est à remarquer que certains de
ces trousseaux de clés seront créés seulement lors de leur première accession.
Trousseaux de clés de processus
Les identifiants de processus eux-mêmes référencent les trousseaux de clés avec des sémantiques
spécifiques. Ces trousseaux de clés sont attachés aussi longtemps que l’ensemble des identifiants
existe, ce qui veut dire habituellement aussi longtemps que le processus existe.
Il existe trois trousseaux de clés avec des règles d’héritage et de partage différentes :
session-keyring(7) (héritage et partage par tous les processus enfant), process-keyring(7)
(partage par tous les threads dans un processus) et thread-keyring(7) (spécifique à un thread
particulier).
Comme alternative à l’utilisation des identifiants réels de trousseau de clés dans les appels à
add_key(2), keyctl(2) et request_key(2), les valeurs spéciales de trousseau de clés
KEY_SPEC_SESSION_KEYRING, KEY_SPEC_PROCESS_KEYRING et KEY_SPEC_THREAD_KEYRING peuvent être
utilisées comme références aux propres instances de l’appelant de ces trousseaux de clés.
Trousseau de clés utilisateur
Chaque UID connu du noyau possède un enregistrement qui contient deux trousseaux de clés :
user-keyring(7) et user-session-keyring(7). Ceux-ci existent aussi longtemps que l’enregistrement
de l’UID existe dans le noyau.
Comme alternative à l’utilisation des identifiants réels de trousseau de clés, dans les appels à
add_key(2), keyctl(2) et request_key(2), les valeurs spéciales de trousseau de clés
KEY_SPEC_USER_KEYRING et KEY_SPEC_USER_SESSION_KEYRING peuvent être utilisées comme références aux
propres instances de l’appelant de ces trousseaux de clés.
Un lien vers le trousseau de clés utilisateur est placé dans le nouveau trousseau de clés de
session par pam_keyinit(8) quand une nouvelle session de connexion est initiée.
Trousseaux de clés persistants
Il existe un persistent-keyring(7) disponible pour chaque UID connu du système. Il peut persister
au-delà de la durée de l’enregistrement de l'UID précédemment mentionné, mais possède un ensemble
de délais d’expiration de telle façon qu’il soit automatiquement nettoyé après un temps défini.
Les trousseaux de clés persistants permettent, par exemple, aux scripts cron(8) d’utiliser les
identifiants laissés dans le trousseau de clés persistant après la déconnexion de l’utilisateur.
Il est à remarquer que le délai d’expiration du trousseau de clés persistant est réinitialisé à
chaque requête du trousseau de clés persistant.
Trousseaux de clés spéciaux
Il existe des trousseaux de clés spéciaux possédés par le noyau qui peuvent ancrer des clés pour
des buts spéciaux. Un exemple de cela est le trousseau de clés système utilisé pour contenir les
clés de chiffrement pour la vérification de signature des modèles.
Ces trousseaux de clés spéciaux sont habituellement fermés à une altération directe par l’espace
utilisateur.
Un « trousseau de clés groupe », originellement prévu pour stocker des clés associées avec chaque GID
connu du noyau, n’est pas encore implémenté et vraisemblablement ne le sera jamais. Néanmoins, la
constante KEY_SPEC_GROUP_KEYRING a été définie pour ce type de trousseau de clés.
Possession
Le concept de possession est important pour comprendre le modèle de sécurité des trousseaux de clés. La
possession par un thread d’une clé est déterminée par les règles suivantes :
(1) Toute clé ou tout trousseau qui n’accorde pas la permission de recherche à l’appelant est ignoré
dans toutes les règles qui suivent.
(2) Un thread possède ses session-keyring(7), process-keyring(7) et thread-keyring(7) directement, car
ces trousseaux de clés sont référencés par ses identifiants.
(3) Si un trousseau de clés est possédé, alors toute clé liée est aussi possédée
(4) Si une clé reliée à un trousseau de clés est elle-même un trousseau de clés, alors la règle (3)
s’applique de manière récursive.
(5) Si le noyau fait un appel montant de processus pour instancier une clé (consultez request_key(2)),
alors il possède aussi les trousseaux de clés du requérant comme dans la règle (1) comme s’il était
le requérant.
La possession n’est pas une propriété fondamentale de la clé, mais doit plutôt être calculée à chaque
besoin de la clé.
La possession est conçue pour permettre l’exécution de programmes set-user-ID à partir, par exemple, d’un
interpréteur de commandes d’utilisateur pour accéder aux clés de l’utilisateur. Accorder la permission au
possesseur de la clé tout en la refusant au propriétaire et au groupe de la clé permet d’empêcher l’accès
à la clé sur la base de correspondance D’UID ou GID.
Lorsqu’il crée un trousseau de clés de session, pam_keyinit(8) ajoute un lien à user-keyring(7), ce qui
entraîne que le trousseau de clés d’utilisateur et tout ce qu’il contient sont possédés par défaut.
Droits d’accès
Chaque clé possède les attributs relatifs à la sécurité suivants :
- l’ID de l’utilisateur propriétaire ;
- l’ID du groupe autorisé à accéder à la clé ;
- une étiquette de sécurité ;
- un masque de permissions.
Le masque de permissions contient quatre ensembles de droits. Les trois premiers ensembles sont
mutuellement exclusifs. Un et seulement un ensemble sera effectif pour une vérification particulière
d’accès. Dans l’ordre décroissant de priorité, ces trois ensembles sont :
user Cet ensemble indique les droits accordés si l’ID utilisateur de clé correspond à l’ID utilisateur
de système de fichiers de l’appelant.
group Cet ensemble indique les droits accordés si l’ID utilisateur ne correspond pas et que l’ID groupe
de clé correspond au GID du système de fichiers de l’appelant ou à un de ses ID groupe
supplémentaires.
other Cet ensemble indique les droits accordés si ni l’ID utilisateur ni l’Id groupe de la clé ne
correspondent.
Le quatrième ensemble de droits est :
possessor
Cet ensemble indique les droits accordés s’il est établi que l’appelant possède la clé.
L’ensemble complet des droits pour une clé est l’union de tout ce qui est applicable des trois premiers
ensembles et du quatrième ensemble si la clé est possédée.
L’ensemble des droits qui peuvent être accordés dans chacun des quatre masques est comme suit :
view Les attributs de la clé peuvent être lus. Cela comprend le type, la description et les droits
d’accès (à l’exclusion de l’étiquette de sécurité).
read Pour une clé, sa charge utile peut être lue, pour un trousseau de clés, la liste des numéros de
série (clés) auxquels le trousseau de clés est lié peut être lue.
write La charge utile de la clé peut être mise à jour et la clé peut être révoquée. Pour un trousseau de
clés, des liens peuvent y être ajoutés ou retirés et le trousseau de clés peut être complètement
effacé (tous les liens sont retirés).
search Pour une clé (ou un trousseau de clés), la clé peut être trouvée par une recherche. Pour un
trousseau de clés, les clés ou trousseaux de clés liés peuvent être retrouvés.
link Des liens peuvent être créés des trousseaux de clés vers la clé. Le lien initial vers une clé qui
est établi quand la clé est créée n’a nul besoin de cette permission.
setattr
Les détails de possession et l’étiquette de sécurité de la clé peuvent être modifiés, le délai
d’expiration de la clé peut être réglé et la clé peut être révoquée.
En plus des droits d’accès, tout module de sécurité de Linux (LSM) peut empêcher l’accès à une clé si sa
politique l’indique. Une clé peut recevoir une étiquette de sécurité ou un autre attribut par le LSM.
Cette étiquette est récupérable à l’aide de keyctl_get_security(3).
Consultez keyctl_chown(3), keyctl_describe(3), keyctl_get_security(3), keyctl_setperm(3) et selinux(8)
pour davantage d’informations.
Recherche de clés
Une des caractéristiques principales de la fonctionnalité de gestion de clés de Linux est la possibilité
de trouver la clé qu’un processus conserve. L’appel système request_key(2) est le premier point d’accès
pour les applications en espace utilisateur pour trouver la clé. En interne, le noyau a quelque chose de
similaire disponible pour une utilisation par les composants internes qui utilisent des clés.
L’algorithme de recherche fonctionne comme suit :
(1) Les trousseaux de clés des processus sont recherchés dans l’ordre suivant : le thread-keyring(7)
s’il existe, le process-keyring(7) s’il existe et ensuite soit le session-keyring(7) s’il existe ou
le user-session-keyring(7) s’il existe.
(2) Si l’appelant était un processus invoqué par le mécanisme d’appel montant request_key(2), alors les
trousseaux de clés de l’appelant originel de request_key(2) seront aussi recherchés.
(3) La recherche dans l’arbre des trousseaux est faite en largeur : chaque trousseau de clés est d’abord
parcouru pour une correspondance puis les trousseaux de clés référencés par ce trousseau sont
parcourus.
(4) Si une clé correspondante valable est trouvée, alors la recherche se termine et cette clé est
renvoyée.
(5) Si une clé correspondante est trouvée à laquelle est attaché un état d’erreur, cet état d’erreur est
noté et la recherche continue.
(6) Si aucune clé correspondante valable n’est trouvée, alors le premier état d’erreur est renvoyé.
Autrement, une erreur ENOKEY est renvoyée.
Il est aussi possible de rechercher une clé particulière, auquel cas seules les étapes (3) à (6)
s’appliquent.
Consultez request_key(2) et keyctl_search(3) pour davantage d’informations.
Création à la demande de clé
Si une clé ne peut être trouvée, et si un argument callout_info est fourni, request_key(2) créera une
nouvelle clé et un appel montant dans l’espace utilisateur instanciera la clé. Cela permet de créer des
clés selon les besoins.
Classiquement, cela impliquera la création d’un nouveau processus par le noyau qui exécutera le programme
request-key(8), qui lui-même exécutera alors le gestionnaire approprié basé sur sa configuration.
Une clé d’autorisation spéciale est passée au gestionnaire qui lui permet, lui et seulement lui,
d’instancier la nouvelle clé. Cela est aussi utilisé pour permettre des recherches réalisées par le
programme gestionnaire pour aussi rechercher les trousseaux de clés du requérant.
Consultez request_key(2), keyctl_assume_authority(3), keyctl_instantiate(3), keyctl_negate(3),
keyctl_reject(3), request-key(8) et request-key.conf(5) pour davantage d’informations.
Utilisateurs
La fonctionnalité de gestion de clés de Linux a un certain nombre d’utilisateurs et d’usages, mais n’est
pas limitée à ce qui existe déjà.
Les utilisateurs du noyau de cette fonctionnalité comprennent :
Systèmes de fichiers réseau – DNS
Le noyau utilise le mécanisme d’appel montant fourni par les clés pour un appel montant dans
l’espace utilisateur pour des recherches DNS et puis pour mettre en cache les résultats.
AF_RXRPC et kAFS – Authentification
Le protocole réseau AF_RXRPC et le système de fichiers AFS interne au noyau utilisent les clés
pour enregistrer le ticket nécessaire pour un trafic sécurisé ou chiffré. Celles-ci sont
recherchées par les opérations réseau lors d’opérations AF_RXRPC et de système de fichiers sur
kAFS.
NFS – Mappage d’ID utilisateur
Le système de fichiers NFS utilise des clés pour stocker les mappages d’ID utilisateur étrangers à
des ID utilisateur locaux.
CIFS – Mot de passe
Le système de fichiers CIFS utilise des clés pour stocker les mots de passe pour l'accès à des
partages distants.
Vérification de module
Le processus de construction du noyau peut être conduit pour une signature chiffrée des modules.
Les utilisateurs de l’espace utilisateur de cette fonctionnalité incluent :
Stockage de clés Kerberos
La fonctionnalité Kerberos 5 du MIT (libkrb5) peut utiliser des clés pour stocker les jetons
d’authentification. Cela peut servir à les supprimer automatiquement après une durée définie
lorsque l'utilisateur les a utilisés pour la dernière fois, mais pendant ce temps leur permettre
de se maintenir jusqu'à ce que l'utilisateur se soit déconnecté de façon à ce que les scripts
cron(8) puissent les utiliser.
FICHIERS
Le noyau fournit divers fichiers /proc qui exposent les informations concernant les clés ou qui
définissent les limites d’utilisation des clés.
/proc/keys (depuis Linux 2.6.10)
Ce fichier expose une liste de clés pour laquelle le thread lecteur possède la permission view,
fournissant diverses informations à propos de chaque clé. Il n'est pas nécessaire que le thread
possède la clé pour que cette dernière soit visible dans ce fichier.
Les seules clés incluses dans la liste sont celles qui accordent la permission view au processus
lecteur (indépendamment du fait qu’il les possède ou non). Les vérifications de sécurité LSM sont
toujours réalisées et peuvent supprimer par filtrage d’autres clés que le processus n’est pas
autorisé à voir.
Voici un exemple de données pouvant être vues dans ce fichier (avec un numérotage des colonnes
pour une référence facile dans les explications) :
(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
Les champs affichés dans chaque ligne du fichier sont les suivants :
ID (1) L’Id (numéro de série) de la clé exprimé en hexadécimal.
Indicateurs (2)
Un ensemble d’indicateurs décrivant l’état de la clé :
I La clé a été instanciée.
R La clé a été révoquée.
D La clé est morte (c’est-à-dire que le type de clé n’est plus enregistré). Une clé
peut être brièvement dans cet état lors de la collecte par le ramasse-miettes.
Q La clé contribue au quota de l’utilisateur.
U La clé est en cours de construction à l’aide d’une fonction de rappel dans l’espace
utilisateur. Consultez request-key(2).
N La clé est instanciée négativement.
i La clé a été invalidée.
Utilisation (3)
C’est un comptage du nombre de structures d’identifiant qui épinglent la clé
(approximativement, le nombre de références de threads et de fichiers ouverts qui se
réfèrent à cette clé).
Durée (4)
Le délai avant que la clé n’expire, exprimé sous forme compréhensible (semaines, jours,
heures, minutes et secondes). La chaîne perm signifie ici que la clé est permanente (aucun
délai). La chaîne expd signifie que la clé a déjà expirée, mais n’a pas été collectée par
le ramasse-miettes.
Permissions (5)
Les permissions de clé, exprimées sous forme de quatre octets hexadécimaux contenant, de
gauche à droite, le possesseur, l’utilisateur, le groupe et les autres permissions. À
l’intérieur de chaque octet, les bits de permission sont comme suit :
0x01 view
0x02 read
0x04 write
0x08 search
0x10 link
0x20 setattr
UID (6)
L’ID utilisateur du possesseur de la clé.
GID (7)
L’ID de groupe de la clé. La valeur -1 signifie ici que la clé n’a pas d’ID de groupe. Cela
peut se produire dans certaines circonstances pour des clés créées par le noyau.
Type (8)
Le type de clé (utilisateur, trousseau de clés, etc.)
Description (9)
La description de la clé (nom). Ce champ contient une information descriptive à propos de
la clé. Pour la plupart des types de clé, elle a la forme
nom[: extra-info]
Le sous-champ nom est la description de la clé (nom). Le champ facultatif extra-info
fournit quelques autres informations à propos de la clé. Les informations qui apparaissent
comme suit dépendent du type de clé :
"user" et "logon"
La taille en octets de la charge utile de la clé (exprimée en décimal).
"keyring"
Le nombre de clés liées au trousseau de clés ou la chaîne empty s’il n’existe aucune
clé liée au trousseau.
"big_key"
La taille de la charge utile en octets, suivie soit par la chaîne [file] si la
charge utile de la clé excède le seuil signifiant que la charge utile est stockée
dans un système de fichiers tmpfs(5) (swappable), ou autrement la chaîne [buff]
indiquant que la clé est suffisamment petite pour résider dans la mémoire du noyau.
Pour le type de clé « .request_key_auth » (clé d’autorisation, consultez request_key(2)),
le champ de description a la forme montrée dans l’exemple suivant :
key:c9a9b19 pid:28880 ci:10
Les trois sous-champs sont comme suit :
key L’ID hexadécimal de la clé en cours d’instanciation dans le programme requérant.
pid Le PID du programme requérant.
ci La taille des annotations avec lesquelles la clé demandée devrait être instanciée
(c’est-à-dire la taille de la charge utile associée avec la clé d’autorisation).
/proc/key-users (depuis Linux 2.6.10)
Ce fichier liste diverses informations pour chaque ID utilisateur qui possède au moins une clé
dans le système. Voici un exemple des données visibles dans ce fichier :
0: 10 9/9 2/1000000 22/25000000
42: 9 9/9 8/200 106/20000
1000: 11 11/11 10/200 271/20000
Les champs affichés dans chaque ligne sont les suivants :
uid L’ID utilisateur.
usage Il s’agit d’un comptage d’utilisation interne au noyau pour la structure utilisée pour
enregistrer les utilisateurs de clé.
nkeys/nikeys
Le nombre total de clé possédées par l’utilisateur et le nombre de clés ayant été
instanciées.
qnkeys/maxkeys
Le nombre de clés possédées par l’utilisateur et le nombre maximal de clés que
l’utilisateur peut posséder.
qnbytes/maxbytes
Le nombre d’octets utilisés dans les charges utiles des clés possédées par l’utilisateur et
la limite haute du nombre d’octets dans les charges utiles des clés pour cet utilisateur.
/proc/sys/kernel/keys/gc_delay (depuis Linux 2.6.32)
La valeur dans ce fichier indique l’intervalle, en seconde, après lequel les clés révoquées ou
expirées seront collectées par le ramasse-miettes. Cet intervalle a pour but de disposer d'une
fenêtre temporelle pendant laquelle l’espace utilisateur peut voir une erreur (respectivement
EKEYREVOKED et EKEYEXPIRED) qui indique ce qui est arrivé à la clé.
La valeur par défaut dans ce fichier est 300 (c’est-à-dire cinq minutes).
/proc/sys/kernel/keys/persistent_keyring_expiry (depuis Linux 3.13)
Ce fichier définit un intervalle, en secondes, après lequel le programmateur de durée du trousseau
de clés persistant est réinitialisé chaque fois que le trousseau de clés est accédé (à l’aide de
l’opération keyctl_get_persistent(3) ou keyctl(2) KEYCTL_GET_PERSISTENT).
La valeur par défaut dans ce fichier est 259200 (c’est-à-dire trois jours).
Les fichiers suivants (pouvant être modifiés par les processus privilégiés) sont utilisés pour imposer
des quotas sur le nombre de clés et le nombre d’octets de données pouvant être stockés dans les charges
utiles des clés :
/proc/sys/kernel/keys/maxbytes (depuis Linux 2.6.26)
C’est le nombre maximal d’octets de données que les utilisateurs non privilégiés peuvent détenir
dans les charges utiles des clés qu'ils possèdent.
La valeur par défaut dans ce fichier est 20 000.
/proc/sys/kernel/keys/maxkeys (depuis Linux 2.6.26)
C’est le nombre maximal de clés qu’un utilisateur non privilégié peut posséder.
La valeur par défaut dans ce fichier est 200.
/proc/sys/kernel/keys/root_maxbytes (depuis Linux 2.6.26)
C’est le nombre maximal d’octets de données que le superutilisateur (UID 0 dans l’espace de noms
utilisateur racine) peut détenir dans les charges utiles des clés qu'il possède.
La valeur par défaut dans ce fichier est 25 000 000 (20 000 avant Linux 3.17).
/proc/sys/kernel/keys/root_maxkeys (depuis Linux 2.6.26)
C’est le nombre maximal de clés que le superutilisateur (UID 0 dans l’espace de noms utilisateur
racine) peut détenir.
La valeur par défaut dans ce fichier est 1 000 000 (200 avant Linux 3.17).
En ce qui concerne les trousseaux de clés, il est à remarquer que chaque lien dans un trousseau consomme
quatre octets de la charge utile du trousseau.
VOIR AUSSI
keyctl(1), add_key(2), keyctl(2), request_key(2), keyctl(3), keyutils(7), persistent-keyring(7),
process-keyring(7), session-keyring(7), thread-keyring(7), user-keyring(7), user-session-keyring(7),
pam_keyinit(8), request-key(8)
linux.git/Documentation/crypto/asymmetric-keys.txt
linux.git/Documentation/security/keys/
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org>, David Prévot
<david@tilapin.org> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
Pages du manuel de Linux 6.9.1 16 juin 2024 keyrings(7)