Provided by: manpages-fr_4.13-4_all bug

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.10 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 ⟨⟩.