keyrings(7) Miscellaneous Information Manual keyrings(7)
NOM
keyrings - Gestion interne au noyau de cles et memorisation
DESCRIPTION
La fonction de gestion de cles de Linux est principalement un moyen
pour divers composants du noyau de memoriser ou de mettre en cache des
donnees de securite, des cles d'authentification, des cles de
chiffrement et d'autres donnees dans le noyau.
Les interfaces d'appel systeme sont fournies de facon a ce que les
programmes en espace utilisateur puissent gerer ces objets, et aussi en
utiliser la fonctionnalite pour leurs propres besoins. Consultez
add_key(2), request_key(2) et keyctl(2).
Une bibliotheque et quelques utilitaires en espace utilisateur sont
fournis pour autoriser l'acces a cette fonctionnalite. Consultez
keyctl(1), keyctl(3) et keyutils(7) pour davantage d'informations.
Cles
Une cle possede les attributs suivants :
Numero de serie (ID)
IL s'agit d'un entier unique par lequel une cle est referencee
dans des appels systeme. Le numero de serie est parfois appele
de maniere synonyme l'identifiant de cle. En programmation, les
numeros de serie sont representes en utilisant le type
key_serial_t.
Type Le type de cle precise quelle sorte de donnees sera geree par la
cle, de quelle maniere le contenu presente par la cle sera
analyse et comment la charge utile sera utilisee.
Un certain nombre de types generiques sont disponibles en plus
de types specialises definis par des composants particuliers du
noyau.
Description (nom)
La description de la cle est une chaine affichable qui est
utilisee comme terme de recherche de la cle (conjointement avec
le type de la cle) ainsi que comme nom a afficher. Lors des
recherches, la description peut correspondre partiellement ou
totalement.
Charge utile (donnees)
La charge utile est le contenu reel de la cle. Elle est
habituellement definie au moment de la creation de la cle, mais
il est possible qu'un appel montant (upcall) du noyau dans
l'espace utilisateur finisse l'instanciation de la cle si
celle-ci n'etait pas connue du noyau quand elle a ete demandee.
Pour plus de details, consultez request_key(2).
Une charge utile de cle peut etre lue et mise a jour si le type
de cle le gere et si les permissions adequates sont donnees a
l'appelant.
Droits d'acces
De la meme maniere que pour les fichiers, chaque cle possede un
ID utilisateur, un ID de groupe et une etiquette de securite.
Chaque cle possede aussi un ensemble de permissions, mais il en
existe plus que pour un fichier UNIX normal, et il existe une
categorie supplementaire - possesseur -- en plus des
utilisateur, groupe et autres. Consultez Possession,
ci-dessous).
Il est a remarquer que les cles sont sujettes a un quota
puisqu'elles necessitent de la memoire du noyau non
<< swappable >>. L'ID de l'utilisateur proprietaire indique quel
quota doit etre debite.
Heure d'expiration
Chaque cle peut avoir une heure d'expiration definie. Quand ce
moment est atteint, la cle est marquee comme perimee et une
demande d'acces a celle-ci echouera avec l'erreur EKEYEXPIRED.
Si elle n'est pas supprimee, mise a jour ou remplacee, alors
apres un certain temps, la cle ayant expiree est automatiquement
supprimee (collectee par le ramasse-miettes) avec tous les liens
vers elle, et toute tentative d'acces a cette cle echouera avec
l'erreur ENOKEY.
Comptage de references
Chaque cle possede un comptage de references. Les cles sont
referencees par des trousseaux de cles, par les utilisateurs
actuellement actifs, et par les identifiants d'un processus.
Quand le comptage de references atteint zero, la cle est
programmee pour le ramasse-miettes.
Types de cle
Le noyau fournit plusieurs types basiques de cle :
"keyring"
Les trousseaux de cles sont des cles speciales qui stockent un
ensemble de liens vers d'autres cles (incluant d'autres
trousseaux de cles), de maniere analogue a un repertoire
contenant des liens vers des fichiers. L'objectif principal d'un
trousseau de cles est d'empecher d'autres cles d'etre collectees
par le ramasse-miettes parce qu'elles ne servent de references a
rien.
Les trousseaux de cles avec des descriptions (noms) commencant
par un point (.) sont reservees a l'implementation.
"user" Il s'agit d'un type de cle generique. La cle est entierement
conservee dans la memoire du noyau. La charge utile peut etre
lue et mise a jour par des applications de l'espace utilisateur.
La charge utile des cles de ce type est un objet binaire (blob)
de donnees arbitraires pouvant contenir 32 767 octets.
La description peut etre n'importe quelle chaine autorisee, bien
qu'il soit preferable qu'elle commence par un prefixe delimite
par un deux-points representant le service auquel la cle est
destinee (par exemple, << afs:mykey >>).
"logon" (depuis Linux 3.3)
Ce type de cle est fondamentalement identique a << user >>, mais
ne permet pas la lecture (c'est-a-dire l'operation KEYCTL_READ
de keyctl(2)), signifiant que la charge utile n'est jamais
visible a partir de l'espace utilisateur. Cela est adapte au
stockage de paires nom d'utilisateur/mot de passe qui ne doivent
pas etre lisibles a partir de l'espace utilisateur.
La description de la cle << logon >> doit debuter par un prefixe
non vide delimite par un deux-points dont le but est
d'identifier le service auquel la cle appartient. Il est a
remarquer que cela differe du type de cle << user >> ou
l'incorporation du prefixe est recommandee mais pas obligee.
"big_key" (depuis Linux 3.13)
Ce type de cle est semblable au type << user >> de cle, mais il
peut contenir une charge utile de taille 1 MiB. Ce type de cle
est utile pour, par exemple, contenir des caches de ticket
Kerberos.
Les donnees de la charge utile peuvent etre stockees dans un
systeme de fichiers tmpfs, plutot que dans la memoire du noyau
si la taille des donnees excede la surcharge due au stockage des
donnees dans le systeme de fichiers. Stocker les donnees dans un
systeme de fichiers necessite que des structures de systeme de
fichiers soient allouees dans le noyau. La taille de ces
structures determine le seuil au-dessus duquel la methode tmpfs
de stockage est utilisee. Depuis Linux 4.8, les donnees de la
charge utile sont chiffrees lorsqu'elles sont stockees en tmpfs,
empechant par consequentqu'elles soient ecrites dans l'espace
d'echange sans etre chiffrees.
Il existe aussi d'autres types de cle specialises, mais ils ne sont pas
evoques ici, car ils ne sont pas destines a une utilisation normale en
espace utilisateur.
Les noms de type de cle qui commencent par un point (.) sont reserves a
l'implementation.
Trousseaux de cles
Comme indique precedemment, les trousseaux de cles sont un type special
de cle qui contient des liens vers d'autres cles (pouvant inclure
d'autres trousseaux de cles). Les cles peuvent etre liees a plusieurs
trousseaux de cles. Les trousseaux de cles peuvent etre consideres
comme analogues a des repertoires UNIX ou chaque repertoire contient un
ensemble de liens physiques vers des fichiers.
Differentes operations (appels systeme) ne peuvent etre appliquees
qu'aux trousseaux de cles :
Ajout Une cle peut etre ajoutee dans un trousseau de cles par les
appels systeme ayant cree les cles. Cela evite que la nouvelle
cle soit detruite immediatement quand l'appel systeme libere la
derniere reference a la cle.
Liaison
Un lien peut etre ajoute a un trousseau de cles pointant vers
une cle deja connue, si cela ne cree pas de cycle
d'auto-referencement.
Deliaison
Un lien peut etre supprime d'un trousseau de cles. Quand le
dernier lien vers une cle est supprime, cette cle sera
programmee pour etre collectee par le ramasse-miettes.
Effacement
Tous les liens peuvent etre supprimes d'un trousseau de cles.
Recherche
Un trousseau de cles peut etre considere comme la racine d'un
arbre ou d'un sous-arbre dans lesquels les trousseaux de cles
forment les branches et le reste les feuilles. Cet arbre peut
etre parcouru pour rechercher une cle 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.
Cles d'ancrage
Pour empecher une cle d'etre collectee par le ramasse-miettes, elle
doit etre ancree pour conserver son comptage de references en cours
lorsqu'elle n'est pas utilisee activement par le noyau.
Les trousseaux de cles sont utilises pour ancrer d'autres cles. Chaque
lien est une reference a une cle. Il est a remarquer que les trousseaux
de cles sont eux-memes des cles et sont aussi sujets a la meme
necessite d'ancrage pour empecher qu'ils soient collectes par le
ramasse-miettes.
Le noyau propose un certain nombre de trousseaux de cles d'ancrage. Il
est a remarquer que certains de ces trousseaux de cles seront crees
seulement lors de leur premiere accession.
Trousseaux de cles de processus
Les identifiants de processus eux-memes referencent les
trousseaux de cles avec des semantiques specifiques. Ces
trousseaux de cles sont attaches aussi longtemps que l'ensemble
des identifiants existe, ce qui veut dire habituellement aussi
longtemps que le processus existe.
Il existe trois trousseaux de cles avec des regles d'heritage et
de partage differentes : session-keyring(7) (heritage et partage
par tous les processus enfant), process-keyring(7) (partage par
tous les threads dans un processus) et thread-keyring(7)
(specifique a un thread particulier).
Comme alternative a l'utilisation des identifiants reels de
trousseau de cles dans les appels a add_key(2), keyctl(2) et
request_key(2), les valeurs speciales de trousseau de cles
KEY_SPEC_SESSION_KEYRING, KEY_SPEC_PROCESS_KEYRING et
KEY_SPEC_THREAD_KEYRING peuvent etre utilisees comme references
aux propres instances de l'appelant de ces trousseaux de cles.
Trousseau de cles utilisateur
Chaque UID connu du noyau possede un enregistrement qui contient
deux trousseaux de cles : 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 a l'utilisation des identifiants reels de
trousseau de cles, dans les appels a add_key(2), keyctl(2) et
request_key(2), les valeurs speciales de trousseau de cles
KEY_SPEC_USER_KEYRING et KEY_SPEC_USER_SESSION_KEYRING peuvent
etre utilisees comme references aux propres instances de
l'appelant de ces trousseaux de cles.
Un lien vers le trousseau de cles utilisateur est place dans le
nouveau trousseau de cles de session par pam_keyinit(8) quand
une nouvelle session de connexion est initiee.
Trousseaux de cles persistants
Il existe un persistent-keyring(7) disponible pour chaque UID
connu du systeme. Il peut persister au-dela de la duree de
l'enregistrement de l'UID precedemment mentionne, mais possede
un ensemble de delais d'expiration de telle facon qu'il soit
automatiquement nettoye apres un temps defini. Les trousseaux de
cles persistants permettent, par exemple, aux scripts cron(8)
d'utiliser les identifiants laisses dans le trousseau de cles
persistant apres la deconnexion de l'utilisateur.
Il est a remarquer que le delai d'expiration du trousseau de
cles persistant est reinitialise a chaque requete du trousseau
de cles persistant.
Trousseaux de cles speciaux
Il existe des trousseaux de cles speciaux possedes par le noyau
qui peuvent ancrer des cles pour des buts speciaux. Un exemple
de cela est le trousseau de cles systeme utilise pour contenir
les cles de chiffrement pour la verification de signature des
modeles.
Ces trousseaux de cles speciaux sont habituellement fermes a une
alteration directe par l'espace utilisateur.
Un << trousseau de cles groupe >>, originellement prevu pour stocker
des cles associees avec chaque GID connu du noyau, n'est pas encore
implemente et vraisemblablement ne le sera jamais. Neanmoins, la
constante KEY_SPEC_GROUP_KEYRING a ete definie pour ce type de
trousseau de cles.
Possession
Le concept de possession est important pour comprendre le modele de
securite des trousseaux de cles. La possession par un thread d'une cle
est determinee par les regles suivantes :
(1) Toute cle ou tout trousseau qui n'accorde pas la permission de
recherche a l'appelant est ignore dans toutes les regles qui
suivent.
(2) Un thread possede ses session-keyring(7), process-keyring(7) et
thread-keyring(7) directement, car ces trousseaux de cles sont
references par ses identifiants.
(3) Si un trousseau de cles est possede, alors toute cle liee est
aussi possedee
(4) Si une cle reliee a un trousseau de cles est elle-meme un
trousseau de cles, alors la regle (3) s'applique de maniere
recursive.
(5) Si le noyau fait un appel montant de processus pour instancier une
cle (consultez request_key(2)), alors il possede aussi les
trousseaux de cles du requerant comme dans la regle (1) comme s'il
etait le requerant.
La possession n'est pas une propriete fondamentale de la cle, mais doit
plutot etre calculee a chaque besoin de la cle.
La possession est concue pour permettre l'execution de programmes
set-user-ID a partir, par exemple, d'un interpreteur de commandes
d'utilisateur pour acceder aux cles de l'utilisateur. Accorder la
permission au possesseur de la cle tout en la refusant au proprietaire
et au groupe de la cle permet d'empecher l'acces a la cle sur la base
de correspondance D'UID ou GID.
Lorsqu'il cree un trousseau de cles de session, pam_keyinit(8) ajoute
un lien a user-keyring(7), ce qui entraine que le trousseau de cles
d'utilisateur et tout ce qu'il contient sont possedes par defaut.
Droits d'acces
Chaque cle possede les attributs relatifs a la securite suivants :
- l'ID de l'utilisateur proprietaire ;
- l'ID du groupe autorise a acceder a la cle ;
- une etiquette de securite ;
- 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 verification particuliere d'acces. Dans
l'ordre decroissant de priorite, ces trois ensembles sont :
user Cet ensemble indique les droits accordes si l'ID utilisateur de
cle correspond a l'ID utilisateur de systeme de fichiers de
l'appelant.
group Cet ensemble indique les droits accordes si l'ID utilisateur ne
correspond pas et que l'ID groupe de cle correspond au GID du
systeme de fichiers de l'appelant ou a un de ses ID groupe
supplementaires.
other Cet ensemble indique les droits accordes si ni l'ID utilisateur
ni l'Id groupe de la cle ne correspondent.
Le quatrieme ensemble de droits est :
possessor
Cet ensemble indique les droits accordes s'il est etabli que
l'appelant possede la cle.
L'ensemble complet des droits pour une cle est l'union de tout ce qui
est applicable des trois premiers ensembles et du quatrieme ensemble si
la cle est possedee.
L'ensemble des droits qui peuvent etre accordes dans chacun des quatre
masques est comme suit :
view Les attributs de la cle peuvent etre lus. Cela comprend le type,
la description et les droits d'acces (a l'exclusion de
l'etiquette de securite).
read Pour une cle, sa charge utile peut etre lue, pour un trousseau
de cles, la liste des numeros de serie (cles) auxquels le
trousseau de cles est lie peut etre lue.
write La charge utile de la cle peut etre mise a jour et la cle peut
etre revoquee. Pour un trousseau de cles, des liens peuvent y
etre ajoutes ou retires et le trousseau de cles peut etre
completement efface (tous les liens sont retires).
search Pour une cle (ou un trousseau de cles), la cle peut etre trouvee
par une recherche. Pour un trousseau de cles, les cles ou
trousseaux de cles lies peuvent etre retrouves.
link Des liens peuvent etre crees des trousseaux de cles vers la cle.
Le lien initial vers une cle qui est etabli quand la cle est
creee n'a nul besoin de cette permission.
setattr
Les details de possession et l'etiquette de securite de la cle
peuvent etre modifies, le delai d'expiration de la cle peut etre
regle et la cle peut etre revoquee.
En plus des droits d'acces, tout module de securite de Linux (LSM) peut
empecher l'acces a une cle si sa politique l'indique. Une cle peut
recevoir une etiquette de securite ou un autre attribut par le LSM.
Cette etiquette est recuperable a 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 cles
Une des caracteristiques principales de la fonctionnalite de gestion de
cles de Linux est la possibilite de trouver la cle qu'un processus
conserve. L'appel systeme request_key(2) est le premier point d'acces
pour les applications en espace utilisateur pour trouver la cle. En
interne, le noyau a quelque chose de similaire disponible pour une
utilisation par les composants internes qui utilisent des cles.
L'algorithme de recherche fonctionne comme suit :
(1) Les trousseaux de cles des processus sont recherches 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 etait un processus invoque par le mecanisme d'appel
montant request_key(2), alors les trousseaux de cles de l'appelant
originel de request_key(2) seront aussi recherches.
(3) La recherche dans l'arbre des trousseaux est faite en largeur :
chaque trousseau de cles est d'abord parcouru pour une
correspondance puis les trousseaux de cles references par ce
trousseau sont parcourus.
(4) Si une cle correspondante valable est trouvee, alors la recherche
se termine et cette cle est renvoyee.
(5) Si une cle correspondante est trouvee a laquelle est attache un
etat d'erreur, cet etat d'erreur est note et la recherche
continue.
(6) Si aucune cle correspondante valable n'est trouvee, alors le
premier etat d'erreur est renvoye. Autrement, une erreur ENOKEY
est renvoyee.
Il est aussi possible de rechercher une cle particuliere, auquel cas
seules les etapes (3) a (6) s'appliquent.
Consultez request_key(2) et keyctl_search(3) pour davantage
d'informations.
Creation a la demande de cle
Si une cle ne peut etre trouvee, et si un argument callout_info est
fourni, request_key(2) creera une nouvelle cle et un appel montant dans
l'espace utilisateur instanciera la cle. Cela permet de creer des cles
selon les besoins.
Classiquement, cela impliquera la creation d'un nouveau processus par
le noyau qui executera le programme request-key(8), qui lui-meme
executera alors le gestionnaire approprie base sur sa configuration.
Une cle d'autorisation speciale est passee au gestionnaire qui lui
permet, lui et seulement lui, d'instancier la nouvelle cle. Cela est
aussi utilise pour permettre des recherches realisees par le programme
gestionnaire pour aussi rechercher les trousseaux de cles du requerant.
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 cles ou qui definissent les limites d'utilisation des
cles.
/proc/keys (depuis Linux 2.6.10)
Ce fichier expose une liste de cles pour laquelle le thread
lecteur possede la permission view, fournissant diverses
informations a propos de chaque cle. Il n'est pas necessaire que
le thread possede la cle pour que cette derniere soit visible
dans ce fichier.
Les seules cles incluses dans la liste sont celles qui accordent
la permission view au processus lecteur (independamment du fait
qu'il les possede ou non). Les verifications de securite LSM
sont toujours realisees et peuvent supprimer par filtrage
d'autres cles que le processus n'est pas autorise a voir.
Voici un exemple de donnees pouvant etre vues dans ce fichier
(avec un numerotage des colonnes pour une reference 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 affiches dans chaque ligne du fichier sont les
suivants :
ID (1) L'Id (numero de serie) de la cle exprime en hexadecimal.
Indicateurs (2)
Un ensemble d'indicateurs decrivant l'etat de la cle :
I La cle a ete instanciee.
R La cle a ete revoquee.
D La cle est morte (c'est-a-dire que le type de cle
n'est plus enregistre). Une cle peut etre
brievement dans cet etat lors de la collecte par
le ramasse-miettes.
Q La cle contribue au quota de l'utilisateur.
U La cle est en cours de construction a l'aide d'une
fonction de rappel dans l'espace utilisateur.
Consultez request-key(2).
N La cle est instanciee negativement.
i La cle a ete invalidee.
Utilisation (3)
C'est un comptage du nombre de structures d'identifiant
qui epinglent la cle (approximativement, le nombre de
references de threads et de fichiers ouverts qui se
referent a cette cle).
Duree (4)
Le delai avant que la cle n'expire, exprime sous forme
comprehensible (semaines, jours, heures, minutes et
secondes). La chaine perm signifie ici que la cle est
permanente (aucun delai). La chaine expd signifie que la
cle a deja expiree, mais n'a pas ete collectee par le
ramasse-miettes.
Permissions (5)
Les permissions de cle, exprimees sous forme de quatre
octets hexadecimaux contenant, de gauche a droite, le
possesseur, l'utilisateur, le groupe et les autres
permissions. A l'interieur 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 cle.
GID (7)
L'ID de groupe de la cle. La valeur -1 signifie ici que
la cle n'a pas d'ID de groupe. Cela peut se produire dans
certaines circonstances pour des cles creees par le
noyau.
Type (8)
Le type de cle (utilisateur, trousseau de cles, etc.)
Description (9)
La description de la cle (nom). Ce champ contient une
information descriptive a propos de la cle. Pour la
plupart des types de cle, elle a la forme
nom[: extra-info]
Le sous-champ nom est la description de la cle (nom). Le
champ facultatif extra-info fournit quelques autres
informations a propos de la cle. Les informations qui
apparaissent comme suit dependent du type de cle :
"user" et "logon"
La taille en octets de la charge utile de la cle
(exprimee en decimal).
"keyring"
Le nombre de cles liees au trousseau de cles ou la
chaine empty s'il n'existe aucune cle liee au
trousseau.
"big_key"
La taille de la charge utile en octets, suivie
soit par la chaine [file] si la charge utile de la
cle excede le seuil signifiant que la charge utile
est stockee dans un systeme de fichiers tmpfs(5)
(swappable), ou autrement la chaine [buff]
indiquant que la cle est suffisamment petite pour
resider dans la memoire du noyau.
Pour le type de cle << .request_key_auth >> (cle
d'autorisation, consultez request_key(2)), le champ de
description a la forme montree dans l'exemple suivant :
key:c9a9b19 pid:28880 ci:10
Les trois sous-champs sont comme suit :
key L'ID hexadecimal de la cle en cours
d'instanciation dans le programme requerant.
pid Le PID du programme requerant.
ci La taille des annotations avec lesquelles la cle
demandee devrait etre instanciee (c'est-a-dire la
taille de la charge utile associee avec la cle
d'autorisation).
/proc/key-users (depuis Linux 2.6.10)
Ce fichier liste diverses informations pour chaque ID
utilisateur qui possede au moins une cle dans le systeme. Voici
un exemple des donnees 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 affiches 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 utilisee pour enregistrer les
utilisateurs de cle.
nkeys/nikeys
Le nombre total de cle possedees par l'utilisateur et le
nombre de cles ayant ete instanciees.
qnkeys/maxkeys
Le nombre de cles possedees par l'utilisateur et le
nombre maximal de cles que l'utilisateur peut posseder.
qnbytes/maxbytes
Le nombre d'octets utilises dans les charges utiles des
cles possedees par l'utilisateur et la limite haute du
nombre d'octets dans les charges utiles des cles pour cet
utilisateur.
/proc/sys/kernel/keys/gc_delay (depuis Linux 2.6.32)
La valeur dans ce fichier indique l'intervalle, en seconde,
apres lequel les cles revoquees ou expirees seront collectees
par le ramasse-miettes. Cet intervalle a pour but de disposer
d'une fenetre temporelle pendant laquelle l'espace utilisateur
peut voir une erreur (respectivement EKEYREVOKED et EKEYEXPIRED)
qui indique ce qui est arrive a la cle.
La valeur par defaut dans ce fichier est 300 (c'est-a-dire cinq
minutes).
/proc/sys/kernel/keys/persistent_keyring_expiry (depuis Linux 3.13)
Ce fichier definit un intervalle, en secondes, apres lequel le
programmateur de duree du trousseau de cles persistant est
reinitialise chaque fois que le trousseau de cles est accede (a
l'aide de l'operation keyctl_get_persistent(3) ou keyctl(2)
KEYCTL_GET_PERSISTENT).
La valeur par defaut dans ce fichier est 259200 (c'est-a-dire
trois jours).
Les fichiers suivants (pouvant etre modifies par les processus
privilegies) sont utilises pour imposer des quotas sur le nombre de
cles et le nombre d'octets de donnees pouvant etre stockes dans les
charges utiles des cles :
/proc/sys/kernel/keys/maxbytes (depuis Linux 2.6.26)
C'est le nombre maximal d'octets de donnees que les utilisateurs
non privilegies peuvent detenir dans les charges utiles des cles
qu'ils possedent.
La valeur par defaut dans ce fichier est 20 000.
/proc/sys/kernel/keys/maxkeys (depuis Linux 2.6.26)
C'est le nombre maximal de cles qu'un utilisateur non privilegie
peut posseder.
La valeur par defaut dans ce fichier est 200.
/proc/sys/kernel/keys/root_maxbytes (depuis Linux 2.6.26)
C'est le nombre maximal d'octets de donnees que le
superutilisateur (UID 0 dans l'espace de noms utilisateur
racine) peut detenir dans les charges utiles des cles qu'il
possede.
La valeur par defaut 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 cles que le superutilisateur (UID 0
dans l'espace de noms utilisateur racine) peut detenir.
La valeur par defaut dans ce fichier est 1 000 000 (200 avant
Linux 3.17).
En ce qui concerne les trousseaux de cles, il est a remarquer que
chaque lien dans un trousseau consomme quatre octets de la charge utile
du trousseau.
Utilisateurs
La fonctionnalite de gestion de cles de Linux a un certain nombre
d'utilisateurs et d'usages, mais n'est pas limitee a ce qui existe
deja.
Les utilisateurs du noyau de cette fonctionnalite comprennent :
Systemes de fichiers reseau - DNS
Le noyau utilise le mecanisme d'appel montant fourni par les
cles pour un appel montant dans l'espace utilisateur pour des
recherches DNS et puis pour mettre en cache les resultats.
AF_RXRPC et kAFS - Authentification
Le protocole reseau AF_RXRPC et le systeme de fichiers AFS
interne au noyau utilisent les cles pour enregistrer le ticket
necessaire pour un trafic securise ou chiffre. Celles-ci sont
recherchees par les operations reseau lors d'operations AF_RXRPC
et de systeme de fichiers sur kAFS.
NFS - Mappage d'ID utilisateur
Le systeme de fichiers NFS utilise des cles pour stocker les
mappages d'ID utilisateur etrangers a des ID utilisateur locaux.
CIFS - Mot de passe
Le systeme de fichiers CIFS utilise des cles pour stocker les
mots de passe pour l'acces a des partages distants.
Verification de module
Le processus de construction du noyau peut etre conduit pour une
signature chiffree des modules.
Les utilisateurs de l'espace utilisateur de cette fonctionnalite
incluent :
Stockage de cles Kerberos
La fonctionnalite Kerberos 5 du MIT (libkrb5) peut utiliser des
cles pour stocker les jetons d'authentification. Cela peut
servir a les supprimer automatiquement apres une duree definie
lorsque l'utilisateur les a utilises pour la derniere fois, mais
pendant ce temps leur permettre de se maintenir jusqu'a ce que
l'utilisateur se soit deconnecte de facon a 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).
TRADUCTION
La traduction francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
et Jean-Paul Guillonneau
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 31 octobre 2023 keyrings(7)