Provided by: manpages-fr_4.15.0-9_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
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.
Fichiers /proc
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
Ox02 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.
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.
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)
Les fichiers source du noyau Documentation/crypto/asymmetric-keys.txt et dans
Documentation/security/keys (ou, avant Linux 4.13, dans le fichier
Documentation/security/keys.txt).
COLOPHON
Cette page fait partie de la publication 5.13 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies et la dernière version de cette
page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.