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.
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.
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.
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.
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.
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.
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.
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.
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.
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.