user_namespaces
Table des matières
Retour à l'index
NOM
user_namespaces — Présentation des espaces de noms utilisateur sous Linux
DESCRIPTION
Pour une présentation générale des espaces de noms, consultez
namespaces(7).
Les espaces de noms utilisateur isolent les identifiants et attributs liés à
la sécurité, en particulier les identifiants d'utilisateurs et de groupes
(consultez credentials(7)), le répertoire racine, les clefs (consultez
keyctl(2)) et les capacités (consultez capabilities(7)). Les
identifiants d'utilisateur et de groupe d'un processus peuvent être
différents selon que l'on se trouve à l'intérieur ou à l'extérieur d'un
espace de noms utilisateur. Un processus peut notamment avoir un identifiant
sans privilège particulier en dehors d'un espace de noms et avoir
l'identifiant 0 à l'intérieur d'un espace de noms. Autrement dit, le
processus dispose de tous les privilèges pour des opérations effectuées dans
l'espace de noms, tandis qu'il n'en a aucun pour les opérations réalisées en
dehors de l'espace de noms utilisateur.
Espaces de noms imbriqués, appartenance aux espaces de noms
Les espaces de noms utilisateur peuvent être imbriqués. Cela signifie que
chaque espace de noms utilisateur --- à l'exception de l'espace de noms
initial (« root ») --- a un espace de noms parent et peut avoir
éventuellement un ou plusieurs espaces de noms utilisateur enfant. L'espace
de noms utilisateur parent est l'espace de noms du processus qui a créé
l'espace de noms utilisateur au moyen de unshare(2) ou de clone(2)
invoqué avec l'attribut CLONE_NEWUSER.
Le noyau impose (à partir de Linux 3.11) une limite de 32 niveaux
d'imbrication pour les espaces de noms utilisateur. Si un appel à
unshare(2) ou à clone(2) provoque le dépassement de cette limite, la
commande échoue en renvoyant l'erreur EUSERS.
Chaque processus est membre d'exactement un espace de noms utilisateur. Un
processus créé par fork(2) ou par clone(2) sans l'attribut
CLONE_NEWUSER est membre du même espace de noms que son processus
parent. Un processus mono-threadé peut rejoindre un autre espace de noms en
utilisant setns(2) s'il dispose de la capacité CAP_SYS_ADMIN dans cet
espace de noms ; cette action lui octroie un ensemble de capacités dans cet
espace de noms.
Un appel à clone(2) ou à unshare(2) avec l'attribut CLONE_NEWUSER
place le nouveau processus enfant (pour clone(2)) ou l'appelant (pour
unshare(2)) dans le nouvel espace de noms utilisateur créé par l'appel.
The NS_GET_PARENT ioctl(2) operation can be used to discover the
parental relationship between user namespaces; see ioctl_nsfs(2).
A task that changes one of its effective IDs will have its dumpability reset
to the value in /proc/sys/fs/suid_dumpable. This may affect the
ownership of proc files of child processes and may thus cause the parent to
lack the permissions to write to mapping files of child processes running in
a new user namespace. In such cases making the parent process dumpable,
using PR_SET_DUMPABLE in a call to prctl(2), before creating a child
process in a new user namespace may rectify this problem. See prctl(2)
and proc(5) for details on how ownership is affected.
Capacités
Le processus enfant créé par clone(2) avec l'attribut CLONE_NEWUSER
s’initialise avec un nouvel ensemble de capacités dans le nouvel espace de
noms utilisateur. De même, un processus qui crée un nouvel espace de noms au
moyen de unshare(2) ou qui rejoint un espace de noms existant à l’aide de
setns(2) reçoit un ensemble de capacités dans cet espace de noms. D’un
autre côté, le processus n’a aucune capacité dans le parent (dans le cas de
clone(2)) ou dans le précédent espace de noms utilisateur (dans le cas de
unshare(2) et setns(2)), même si le nouvel espace de noms utilisateur
est créé ou rejoint par l’utilisateur racine (c’est-à-dire un processus avec
l’ID utilisateur 0 dans l’espace de noms racine).
Remarquez qu'un appel à execve(2) déclenche la réévaluation des capacités
selon la méthode habituelle (consultez capabilities(7)), de sorte que le
processus perdra ses capacités, sauf si son identifiant utilisateur vaut 0
dans l'espace de noms ou si le fichier exécutable a un masque de capacités
héritable non vide. Pour en savoir plus, consultez les commentaires sur le
mappage entre utilisateurs et groupes ci-dessous.
Un appel à clone(2) ou unshare(2) en utilisant l'attribut
CLONE_NEWUSER ou un appel à setns(2) qui déplace l’appelant dans
d’autres jeux d’espaces de noms utilisateur positionne les indicateurs
« securebits » (consultez capabilities(7)) à leurs valeurs par défaut
(tous les indicateurs désactivés) dans l’enfant (pour clone(2)) ou
l’appelant (pour unshare(2) ou setns(2)). Remarquez que parce que
l’appelant n’a plus de capacités dans son espace de noms utilisateur après
un appel à setns(2), il n’est pas possible à un processus de
réinitialiser ses indicateurs « securebits » tout en conservant son
appartenance à un espace de noms utilisateur en utilisant une paire d’appels
setns(2) pour se déplacer vers un autre espace de noms utilisateur et
ensuite retourner vers son espace de noms utilisateur original.
Les règles pour déterminer si un processus a ou n’a pas de capacités dans un
espace de noms utilisateur particulier sont comme suit :
- -
-
Un processus dispose d'une capacité dans un espace de noms utilisateur s'il
est membre de cet espace de noms et si cette capacité est activée dans son
jeu de capacités. Un processus peut obtenir une nouvelle capacité dans son
jeu de capacités de plusieurs façons. Il peut, par exemple, exécuter un
programme set-user-ID ou un exécutable avec des capacités de fichier
associées. Il peut également obtenir des capacités à l’aide de l'action de
clone(2), unshare(2) ou setns(2) comme indiqué précédemment.
- -
-
Si un processus dispose d'une capacité dans un espace de noms utilisateur,
alors il a cette même capacité dans tous les espaces de noms enfant (et les
espaces descendants supprimés).
- -
-
When a user namespace is created, the kernel records the effective user ID
of the creating process as being the "owner" of the namespace. A process
that resides in the parent of the user namespace and whose effective user ID
matches the owner of the namespace has all capabilities in the namespace.
By virtue of the previous rule, this means that the process has all
capabilities in all further removed descendant user namespaces as well. The
NS_GET_OWNER_UID ioctl(2) operation can be used to discover the user
ID of the owner of the namespace; see ioctl_nsfs(2).
Effet des capacités à l’intérieur d’un espace de noms utilisateur
Un processus qui possède des capacités dans un espace de noms utilisateur a
la possibilité d'effectuer des opérations (nécessitant des privilèges)
seulement sur les ressources gérées par cet espace de noms. En d’autres
mots, avoir une capacité dans un espace de noms permet à un processus de
réaliser des opérations privilégiées sur des ressources gérées par des
espaces de noms (non utilisateur) possédés par (associés avec) l’espace de
noms utilisateur (consultez la sous-section suivante).
D’un autre coté, il existe beaucoup d’opérations privilégiées affectant les
ressources qui ne sont associées à aucun type d’espace de noms, par exemple,
modifier l’heure du système (c’est-à-dire le calendrier) (régi par
CAP_SYS_TIME), charger un module du noyau (régi par CAP_SYS_MODULE) et
créer un périphérique (régi par CAP_MKNOD). Seuls les processus avec
privilèges dans l’espace de noms initial peuvent réaliser de telles
opérations.
Avoir CAP_SYS_ADMIN dans un espace de noms utilisateur qui possède un
espace de noms de montage de processus permet à ce processus de créer des
remontages (bind mount) et de monter les types suivants de système de
fichiers :
-
- -
-
/proc/ (depuis Linux 3.8)
- -
-
/sys (depuis Linux 3.8)
- -
-
devpts (depuis Linux 3.9)
- -
-
tmpfs(5) (depuis Linux 3.9)
- -
-
ramfs (depuis Linux 3.9)
- -
-
mqueue (depuis Linux 3.9)
- -
-
bpf (depuis Linux 4.4)
- -
-
overlayfs (depuis Linux 5.11)
Holding CAP_SYS_ADMIN within the user namespace that owns a process's
cgroup namespace allows (since Linux 4.6) that process to the mount the
cgroup version 2 filesystem and cgroup version 1 named hierarchies (i.e.,
cgroup filesystems mounted with the "none,name=" option).
Avoir CAP_SYS_ADMIN dans un espace de noms utilisateur qui possède un
espace de noms PID de processus permet (depuis Linux 3.8) à ce processus de
monter des systèmes de fichiers /proc.
Remarquez cependant que le montage de systèmes de fichiers basés sur les
blocs peut être réalisé seulement par un processus ayant CAP_SYS_ADMIN
dans l’espace de noms utilisateur initial.
Liens entre les espaces de noms utilisateur et les autres espaces de noms
À partir de Linux 3.8, les processus sans privilèges peuvent créer des
espaces de noms utilisateur et les autres espaces de noms peuvent être créés
avec simplement la capacité CAP_SYS_ADMIN dans l'espace de noms
utilisateur de l'appelant.
Lorsqu'un espace de noms autre qu'utilisateur est créé, il appartient à
l'espace de noms utilisateur auquel appartenait à ce moment là le processus
à l'origine de la création de cet espace de noms. Les opérations
privilégiées sur des ressources régies par un espace de noms non utilisateur
nécessitent que le processus aient les capacités requises dans l’espace de
noms utilisateur qui possède l’espace de noms non utilisateur.
Si CLONE_NEWUSER est indiqué en complément de l'attribut CLONE_NEW*
lors d'un appel simple à clone(2) ou à unshare(2), l'espace de noms
utilisateur est garanti d'être créé en premier. Cela donne des privilèges à
l’enfant (dans le cas de clone(2)) ou à l'appelant (dans le cas de
unshare(2)) dans les espaces de noms subsistants créés par l'appel. Il
est ainsi possible à un appelant sans privilèges d'indiquer ce jeu
d'attributs.
Lorsqu'un nouvel espace de noms (autre qu’un espace de noms utilisateur) est
créé à l’aide de clone(2) ou unshare(2), le noyau enregistre l'espace
de noms utilisateur du processus créateur comme le propriétaire du nouvel
espace de noms. (Cette association ne peut pas être changée). Lorsqu'un
processus du nouvel espace de noms effectue ensuite une opération
privilégiée sur une ressource globale isolée par l'espace de noms, les
vérifications de permissions sont réalisées en fonction des capacités du
processus dans l'espace de noms utilisateur que le noyau a associé au nouvel
espace de noms. Par exemple, supposons qu’un processus essaie de modifier le
nom d’hôte (sethostname(2)), une ressource régie par l’espace de noms
UTS. Dans ce cas le noyau déterminera quel espace de noms utilisateur
possède l’espace de noms UTS du processus et vérifiera si le processus à la
capacité requise (CAP_SYS_ADMIN) dans cet espace de noms utilisateur.
The NS_GET_USERNS ioctl(2) operation can be used to discover the user
namespace that owns a nonuser namespace; see ioctl_nsfs(2).
Correspondance des identifiants d'utilisateur et de groupe : uid_map et gid_map
Lorsqu'un espace de noms utilisateur est créé, il s'initialise sans établir
de mappage entre ses identifiants utilisateurs (identifiants de groupes) et
ceux de l'espace de noms parent. Les fichiers /proc/pid/uid_map et
/proc/pid/gid_map présentent (à partir de Linux 3.5) le mappage entre
identifiants utilisateur et groupe à l'intérieur de l'espace de noms
utilisateur pour le processus pid. Ces fichiers peuvent être consultés
pour prendre connaissance des mappages dans un espace de noms utilisateur et
peuvent être modifiés (une seule fois) pour définir les mappages.
Les paragraphes suivants décrivent uid_map en détails. gid_map est
parfaitement analogue, chaque instance de « identifiant utilisateur » étant
remplacée par « identifiant groupe ».
Le fichier uid_map présente le mappage entre les identifiants utilisateur
de l'espace de noms utilisateur du processus pid et ceux de l'espace de
noms utilisateur du processus qui a ouvert uid_map (mais consultez la
réserve concernant ce point exposée ci-dessous). En d'autres termes, des
processus qui se trouvent dans différents espaces de noms verront des
valeurs différentes lors de la lecture d'un fichier uid_map selon les
mappages des identifiants utilisateur pour l'espace de noms utilisateur du
processus qui effectue la lecture.
Chaque ligne du fichier uid_map affiche un mappage un-pour-un d'un
intervalle d'identifiants utilisateur contigus de deux espaces de noms
utilisateur. Lorsqu'un espace de noms utilisateur vient d'être créé, ce
fichier est vide. Chaque ligne contient trois nombres délimités par des
espaces. Les deux premiers nombres indiquent les premiers identifiants
utilisateur de chacun des deux espaces de noms. Le troisième nombre indique
la longueur de l'intervalle de mappage. Plus précisément, les champs sont
interprétés de la façon suivante :
- (1)
-
Le début de l'intervalle d'identifiants utilisateur dans l'espace de noms
utilisateur du processus pid.
- (2)
-
Le début de l'intervalle d'identifiants utilisateur auquel mappe
l'identifiant utilisateur indiqué dans le premier champ. Selon que le
processus qui a ouvert le fichier uid_map et le processus pid sont ou
non dans le même espace de noms, le deuxième champ est interprété de l'une
des façons suivantes :
-
- (a)
-
Si les deux processus sont dans différents espaces de noms utilisateur : le
deuxième champ est le début de l'intervalle d'identifiants utilisateur dans
l'espace de noms utilisateur du processus qui a ouvert uid_map.
- (b)
-
Si les deux processus sont dans le même espace de noms utilisateur : le
second champ correspond au début de la séquence d'identifiants utilisateur
dans l'espace de noms utilisateur parent du processus pid. Cela permet au
processus qui a ouvert uid_map (généralement, le processus ouvre
/proc/self/uid_map) de voir le mappage des identifiants utilisateur dans
l'espace de noms utilisateur du processus qui a créé cet espace de noms
utilisateur.
- (3)
-
La longueur de l'intervalle des identifiants utilisateur qui est mappé entre
les deux espaces de noms utilisateur.
Les appels système qui renvoient des identifiants utilisateur (des
identifiant de groupes) --- comme par exemple, getuid(2), getgid(2),
et les champs relatifs aux droits dans la structure renvoyée par
stat(2) --- affichent la valeur de l'identifiant utilisateur
(l'identifiant de groupe) mappé dans l'espace de noms utilisateur de
l'appelant.
Lorsqu'un processus accède à un fichier, ses identifiant utilisateur et
groupe sont mappés dans l’espace de noms utilisateur initial pour pouvoir
vérifier les droits ou pour assigner des identifiants lors de la création
d'un fichier. Lorsqu'un processus obtient les identifiants utilisateur et
groupe d'un fichier par la commande stat(2), les identifiants sont
évalués dans le sens inverse, afin de renvoyer les valeurs relatives aux
mappages des ID utilisateur et de groupe du processus.
L'espace de noms utilisateur initial n'a pas d'espace de noms parent, mais
pour conserver la cohérence, le noyau lui attribue des fichiers de mappage
d'identifiants utilisateur et groupe factices pour cet espace de noms. Si
l'on consulte le fichier uid_map (ou gid_map de la même façon) depuis
une invite de commande dans l'espace de noms initial, on peut voir :
$ cat /proc/$$/uid_map
0 0 4294967295
This mapping tells us that the range starting at user ID 0 in this namespace
maps to a range starting at 0 in the (nonexistent) parent namespace, and the
length of the range is the largest 32-bit unsigned integer. This leaves
4294967295 (the 32-bit signed -1 value) unmapped. This is deliberate:
(uid_t) -1 is used in several interfaces (e.g., setreuid(2)) as a
way to specify "no user ID". Leaving (uid_t) -1 unmapped and unusable
guarantees that there will be no confusion when using these interfaces.
Création des mappages d'ID utilisateur et groupe : écriture dans uid_map et gid_map
Après la création d'un nouvel espace de noms utilisateur, le fichier
uid_map de l'un des processus de l'espace de noms peut être ouvert en
écriture une seule fois pour y consigner le mappage des identifiants
utilisateur dans le nouvel espace de noms utilisateur. Toute tentative
d'écrire plus d'une fois dans un fichier uid_map se solde par un échec
qui renvoie l'erreur EPERM. Des règles analogues s'appliquent aux
fichiers gid_map.
Les lignes inscrites dans uid_map (gid_map) doivent suivre les règles
de validité suivantes :
- -
-
Les trois champs doivent être des nombres valables et le dernier champ doit
être strictement positif.
- -
-
Les lignes doivent se terminer par un saut de ligne.
- -
-
Il y a une limite (arbitraire) du nombre de lignes que peut contenir le
fichier. Dans Linux 4.14 et précédents, la limite est (arbitrairement) de
5 lignes. Depuis Linux 4.15, la limite est de 340 lignes. En outre, le
nombre d'octets inscrits dans le fichier doit être inférieur à la taille
d'une page du système, et l'écriture doit être réalisée au début du fichier
(c’est-à-dire lseek(2) et pwrite(2) ne peuvent être utilisées pour
écrire dans le fichier avec un décalage non nul).
- -
-
L'intervalle d'identifiants utilisateur (ou de groupe) indiqué dans chaque
ligne ne peut recouvrir les intervalles des autres lignes. Dans
l'implémentation initiale (Linux 3.8), cette règle était assurée par une
implémentation plus sommaire qui comprenait une contrainte supplémentaire :
les deux premiers champs de chaque ligne devaient apparaître en ordre
croissant. Cela empêchait cependant la création de mappages valables. Ce
problème a été réglé dans Linux 3.9 et suivants, et toutes les combinaisons
valables de mappages non recouvrantes sont désormais acceptées.
- -
-
Au moins une ligne doit être inscrite dans le fichier.
Les opérations d'écritures qui ne respectent pas les règles énoncées
précédemment échouent en renvoyant l'erreur EINVAL.
Un processus ne peut écrire dans le fichier /proc/pid/uid_map
(/proc/pid/gid_map) qu'à la condition de respecter les contraintes
suivantes :
- -
-
Le processus réalisant l'écriture doit disposer de la capacité CAP_SETUID
(CAP_SETGID) dans l'espace de noms utilisateur du processus pid.
- -
-
Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms
utilisateur du processus pid, soit dans l'espace de noms utilisateur
parent du processus pid.
- -
-
Les identifiants utilisateur (ou groupe) mappés doivent, en retour, avoir un
mappage dans l'espace de noms utilisateur parent.
- -
-
Pour une mise à jour de /proc/pid/uid_map pour créer un mappage pour
l’UID 0 dans l’espace de noms parent, une des propositions suivantes doit
être vraie :
-
- (a)
-
si le processus écrivain est dans l’espace de noms utilisateur parent, il
doit disposer de la capacité CAP_SETUID ;
- (b)
-
si le processus écrivain est dans l’espace de noms enfant, alors le
processus ayant créé l’espace de noms utilisateur doit avoir la capacité
CAP_SETFCAP lors de la création de l’espace de noms.
-
Cette règle a été mise en place depuis Linux 5.12. Elle supprime un bogue
de sécurité précédent à cause duquel un processus d’UID 0 n’ayant pas la
capacité CAP_SETFCAP, qui est nécessaire pour créer un binaire avec les
capacités de fichier d’un certain espace de noms (comme décrit dans
capabilities(7)), pouvait néanmoins créer un tel binaire en effectuant
les étapes suivantes :
-
- (1)
-
Créer un nouvel espace de noms utilisateur avec le mappage d’identifiant
(c’est-à-dire, UID 0 dans le nouvel espace de noms utilisateur correspond à
l’UID 0 dans l’espace de noms parent), ainsi cet UID 0 dans les deux
espaces de noms est équivalent au même ID de superutilisateur.
- (2)
-
Puisque le processus enfant a la capacité CAP_SETFCAP, il peut créer un
binaire avec les capacités de fichier d’un certain espace de noms qui serait
alors disponible dans l’espace de noms parent (parce que les ID du
superutilisateur sont les mêmes dans les deux espaces de noms).
- -
-
L'un des deux points suivants est vérifié :
-
- (a)
-
soit le processus réalisant l'écriture doit disposer de la capacité
CAP_SETUID ( CAP_SETGID) dans l'espace de noms utilisateur parent.
-
- -
-
Aucune autre restriction, le processus peut établir des mappages vers les ID
utilisateur (groupe) dans l’espace de noms parent.
- (b)
-
Ou sinon toutes les restrictions suivantes s’appliquent :
-
- -
-
Les données inscrites dans uid_map (gid_map) doivent consister en une
seule ligne qui mappe l'identifiant utilisateur effectif (groupe) du
processus écrivant dans l’espace de noms utilisateur parent à un ID
utilisateur (groupe) dans l’espace de noms utilisateur.
- -
-
Le processus réalisant l'écriture doit avoir le même ID utilisateur effectif
que le processus ayant créé l’espace de noms utilisateur.
- -
-
Dans le cas de gid_map, l’utilisation de l’appel système setgroups(2)
doit être d’abord interdit en écrivant « deny » dans le fichier
/proc/pid/setgroups (voir ci-dessous) avant d’écrire dans gid_map.
Les écritures violant ces règles échouent avec l’erreur EPERM.
Mappages d’ID de projet : projid_map
De la même manière que pour les mappages d’ID d’utilisateur et de groupe, il
est possible de créer des mappages d’ID de projet pour un espace de noms
utilisateur (les ID de projets sont utilisés pour des quotas de disque,
consulter setquota(8) et quotactl(2)).
Les mappages d’ID de projet sont définis par des écritures dans le fichier
/proc/pid/projid_map (présent depuis Linux 3.7).
Les règles de validité pour écrire dans le fichier
/proc/pid/projid_map sont les mêmes que pour le fichier
uid_map. Une violation de ces règles provoque l'échec de write(2) avec
l’erreur EINVAL.
Les règles de permission pour écrire dans le fichier
/proc/pid/projid_map sont les suivantes :
- -
-
Le processus réalisant l'écriture doit se trouver soit dans l'espace de noms
utilisateur du processus pid, soit dans l'espace de noms utilisateur
parent du processus pid.
- -
-
Les ID de projet mappés doivent, en retour, avoir un mappage dans l'espace
de noms utilisateur parent.
La violation de ces règles provoque l'échec de write(2) avec l’erreur
EPERM.
Interaction avec les appels système qui modifient les UID ou les GID
Dans un espace de noms utilisateur où aucun fichier uid_map n’a été
écrit, les appels système qui modifient l’ID utilisateur échoueront. De la
même manière, si le fichier gid_map n’a pas été écrit, les appels système
modifiant les ID de groupe échoueront. Après que les fichiers uid_map et
gid_map aient été écrits, seules les valeurs mappées peuvent être
utilisées dans les appels système modifiant les ID utilisateur et groupe.
Pour les ID utilisateur, les appels système concernés incluent setuid(2),
setfsuid(2), setreuid(2) et setresuid(2). Pour les ID de groupe,
les appels système concernés incluent setgid(2), setfsgid(2),
setregid(2), setresgid(2) et setgroups(2).
Écrire « deny » dans le fichier /proc/pid/setgroups avant d’écrire
dans /proc/pid/gid_map désactivera de manière permanente
setgroups(2) dans un espace de noms utilisateur et permettra d’écrire
dans /proc/pid/gid_map sans avoir la capacité CAP_SETGID dans
l’espace de noms utilisateur parent.
The /proc/pid/setgroups file
Le fichier /proc/pid/setgroups affichera la chaîne « allow » si les
processus dans l’espace de noms utilisateur qui contient le processus pid
sont autorisés à employer l’appel système setgroups(2). Il affichera
« deny » si setgroups(2) n’est pas autorisé dans cet espace de noms
utilisateur. Remarquez que quelle que soit la valeur dans le fichier
/proc/pid/setgroups (et quelles que soient les capacités du
processus), les appels à setgroups(2) ne sont en outre pas permis si
/proc/pidgid_map n’a pas encore été défini.
Un processus privilégié (un avec la capacité CAP_SYS_ADMIN dans l’espace
de noms) peut écrire une des chaînes « allow » ou « deny » dans ce
fichier avant d’écrire un mappage d’ID de groupe pour cet espace de noms
utilisateur dans le fichier /proc/pid/gid_map. Écrire la chaîne
« deny » empêche tout processus dans l’espace de noms utilisateur
d’employer setgroups(2).
L’idée de ces restrictions décrites dans le paragraphe précédent est qu’il
n'est permis d’écrire dans /proc/pid/setgroups que sil’appel à
setgroups(2) est désactivé parce que /proc/pid/gid_map n’a pas été
défini. Cela garantit qu’un processus ne peut transiter d’un état dans
lequel setgroups(2) est autorisé vers un état dans lequel setgroups(2)
est interdit. Un processus peut transiter seulement de setgroups(2)
interdit vers setgroups(2) autorisé.
La valeur par défaut dans ce fichier dans l’espace de noms utilisateur
initial est « allow ».
Une fois que /proc/pid/gid_map a été écrit (ce qui a pour effet
d’activer setgroups(2) dans l’espace de noms utilisateur), il n’est plus
possible de désactiver setgroups(2) en écrivant « deny » dans
/proc/pid/setgroups (l’écriture échoue avec l’erreur EPERM).
Un espace de noms utilisateur enfant hérite du réglage
/proc/pid/setgroups de son parent.
Si le fichier setgroups a la valeur « deny », alors l’appel système
setgroups(2) ne peut pas par la suite être réactivé (en écrivant
« allow » dans le fichier) dans cet espace de noms utilisateur (toute
tentative échouera avec l’erreur EPERM). Cette restriction se propage
vers les espaces de noms utilisateur enfant de cet espace de noms
utilisateur.
Le fichier /proc/pid/setgroups a été ajouté dans Linux 3.19, mais a
été rétroporté vers plusieurs séries stables du noyau car il corrige un
problème de sécurité. Cela concernait les fichiers avec les permissions
telles que « rwx---rwx ». De tels fichiers accordent moins de permissions au
« group » qu’elles ne donnent à « other ». Cela signifie qu’abandonner les
groupes utilisant setgroups(2) peut permettre un accès au fichier du
processus que celui-ci n’avait pas auparavant. Avant l’existence des espaces
de noms utilisateur cela n’était pas un problème, puisque seul un processus
privilégié (un avec la capacité CAP_SETGID) pouvait appeler
setgroups(2). Cependant, avec l’introduction des espaces de noms
utilisateur, il est devenu possible pour un processus non privilégié de
créer un nouvel espace de noms dans lequel l’utilisateur a tous les
privilèges. Cela permet alors à des utilisateurs anciennement non
privilégiés d’abandonner les groupes et donc obtenir l’accès à des fichiers
auxquels ils ne pouvaient pas accéder. Le fichier /proc/pid/setgroups
a été ajouté pour résoudre le problème de sécurité en refusant à tout chemin
pour un processus non privilégié d’abandonner les groupes avec
setgroups(2).
ID utilisateur et groupe non mappés
Il existe différentes situations dans lesquelles un identifiant utilisateur
(ou de groupe) non mappé peut être exposé dans un espace de noms
utilisateur. Par exemple, le premier processus d'un nouvel espace de noms
utilisateur peut appeler getuid() avant que le mappage des identifiants
utilisateur ait été défini pour l'espace de noms. Dans la plupart de ces
cas, l'identifiant utilisateur non mappé est converti en un identifiant
utilisateur (groupe) au-delà de la limite de débordement ; la valeur par
défaut au delà de cette limite pour un identifiant utilisateur (ou groupe)
est 65534. Consultez les descriptions de /proc/sys/kernel/overflowuid et
de /proc/sys/kernel/overflowgid dans proc(5).
Les situations dans lesquelles des identifiants non mappés sont transformés
de cette façon comprennent les cas des appels système qui renvoient des
identifiants utilisateur (getuid(2), getgid(2) et les appels
similaires), les accréditations passées à l’aide d’un socket de domaine
UNIX, les accréditations renvoyées par stat(2), waitid(2) et les
autres opérations IPC « ctl » IPC_STAT de System V, les accréditations
présentées par /proc/pid/status et les fichiers /proc/sysvipc/*,
les accréditations renvoyées par le champ si_uid de siginfo_t reçues
avec un signal (consultez sigaction(2)), les accréditations écrites dans
le fichier du processus de tenue des comptes (consultez acct(5)) et les
accréditations renvoyées avec des notifications de files de messages POSIX
(consultez mq_notify(3)).
Il est un cas notable où des identifiants d'utilisateur et de groupe non
mappés ne sont pas convertis en des valeurs d’ID correspondantes au-delà
de la limite. Lors de la consultation d'un fichier uid_map ou gid_map
dans lequel il n'y a pas de mappage pour le second champ, ce champ apparaît
comme 4294967295 (-1 représenté comme un entier non signé).
Accession aux fichiers
Dans le but de déterminer les permissions quand un processus non privilégié
accède à un fichier, les accréditations du processus (UID, GID) et les
accréditations du fichier sont en réalité mappées vers ce qu’elles seraient
dans l’espace de noms utilisateur initial et alors comparées pour déterminer
les permissions que le processus possède sur le fichier. La même chose est
valable pour les autres objets qui emploient les accréditations plus le
modèle d’accessibilité avec le masque de permission, tels que les objets IPC
de System V.
Opérations sur les capacités relatives aux fichiers
Certaines capacités permettent à un processus de contourner diverses
restrictions imposées par le noyau lors d’opérations sur des fichiers
possédés par d’autres utilisateurs ou groupes. Ce sont CAP_CHOWN,
CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER et CAP_FSETID.
Dans un espace de noms utilisateur, ces capacités permettent à un processus
de contourner les règles si le processus possède la capacité adéquate sur le
fichier, signifiant que :
- -
-
le processus a la capacité effective adéquate dans son espace de noms
utilisateur;
- -
-
les ID utilisateur et groupe du fichier ont tous les deux des mappages
valables dans l’espace de noms utilisateur.
La capacité CAP_FOWNER est traitée de manière quelque peu
exceptionnelle. Elle permet à un processus de contourner les règles
correspondantes à condition qu’au moins l’ID utilisateur du fichier possède
un mappage dans l’espace de noms utilisateur (c’est-à-dire que l’ID de
groupe du fichier n’a nul besoin d’avoir un mappage valable).
Programmes set-user-ID et set-group-ID
Lorsqu'un processus appartenant à un espace de noms exécute un programme
set-user-ID (set-group-ID), l'identifiant utilisateur (groupe) effectif du
processus dans l'espace de noms est changé à n’importe quelle valeur mappée
pour l’identifiant utilisateur (groupe) du fichier. Cependant, si
l'identifiant utilisateur ou groupe n'a pas de mappage dans l'espace de
noms, le bit set-user-ID (set-group-ID) est ignoré silencieusement : le
nouveau programme est exécuté, mais l'identifiant utilisateur (groupe)
effectif n’est pas modifié. Cela reproduit la sémantique d'exécution d'un
programme set-user-ID ou set-group-ID qui se trouve dans un système de
fichiers monté avec l'indicateur MS_NOSUID, comme indiqué dans
mount(2).
Divers
Lorsque les identifiants utilisateur et groupe d'un processus sont transmis
à l’aide d’un socket de domaine UNIX à un processus d'un autre espace de
noms (consultez la description de SCM_CREDENTIALS dans unix(7)), ils
sont transformés en leur valeur correspondante suivant les mappages des
identifiants utilisateur et groupe du processus réceptionnaire.
STANDARDS
Linux.
NOTES
Au fil des ans, de nombreuses fonctionnalités ont été ajoutées au noyau
Linux mais réservées aux utilisateurs disposant de privilèges du fait de la
confusion qu'elles peuvent induire dans les applications
set-user-ID-root. En général, il n'est pas dangereux d'autoriser un
superutilisateur d'un espace de noms à utiliser ces fonctionnalités parce
qu'il est impossible, dans un espace de noms utilisateur, d'obtenir plus de
droits que ce que peut obtenir le superutilisateur d’un espace de noms
utilisateur.
Superutilisateur global
Le terme de « superutilisateur global » (global root) est parfois utilisé
comme un raccourci pour l’ID 0 dans l’espace de noms utilisateur initial.
Disponibilité
Le noyau doit avoir été configuré avec l'option CONFIG_USER_NS pour
permettre l'utilisation des espaces de noms utilisateur. Ces espaces doivent
également être pris en charge par un ensemble de sous-systèmes du noyau. Si
un sous-système non pris en charge est activé dans le noyau, il n'est pas
possible de configurer la prise en charge des espaces de noms.
Depuis Linux 3.8, la plupart des principaux sous-systèmes prennent en charge
les espaces de noms utilisateur, mais certains systèmes de fichiers n'ont
pas l'infrastructure nécessaire pour mapper les identifiants utilisateur et
groupe entre les espaces de noms utilisateur. Linux 3.9 a fourni
l'infrastructure nécessaire à la prise en charge de nombreux systèmes de
fichiers restants (Plan 9 (9P), Andrew File System (AFS), Ceph, CIFS, CODA,
NFS et OCFS2). Linux 3.12 a apporté la prise en charge du dernier des
principaux systèmes de fichiers non encore géré, XFS.
EXEMPLES
Le programme suivant est conçu pour permettre de s'exercer avec les espaces
de noms utilisateur, comme avec d'autres espaces de noms. Il crée des
espaces de noms tels que définis dans les options de la ligne de commande et
exécute une commande dans ces espaces de noms. Les commentaires et la
fonction usage() dans le programme fournissent une explication détaillée
du programme. La session shell suivante illustre son utilisation.
Tout d'abord, regardons l'environnement d'exécution :
$ uname -rs # à partir de Linux 3.8
Linux 3.8.0
$ id -u # exécuté comme utilisateur sans privilèges
1000
$ id -g
1000
Démarrons maintenant un nouveau shell dans les nouveaux espaces de noms
utilisateur (-U), de montage (-m) et de PID (-p), avec
l'identifiant utilisateur (-M) et groupe (-G) 1000 mappés à 0 dans
l'espace de noms utilisateur :
$ ./userns_child_exec -p -m -U -M '0 1000 1' -G '0 1000 1' bash
Le shell a le PID 1 puisqu'il est le premier processus de l'espace de noms :
bash$ echo $$
1
Lorsque l'on monte un nouveau système de fichiers /proc et que l'on
affiche tous les processus visibles dans le nouvel espace de noms PID, on
constate que le shell peut voir tous les processus qui se trouvent à
l'extérieur de l'espace de noms PID :
bash$ mount -t proc proc /proc
bash$ ps ax
PID TTY STAT TIME COMMAND
1 pts/3 S 0:00 bash
22 pts/3 R+ 0:00 ps ax
Dans l'espace de noms utilisateur, le shell a les identifiants utilisateur
et groupe 0, ainsi qu'un ensemble complet de capacités autorisées et
effectives :
bash$ cat /proc/$$/status | egrep 'ha[UG]id'
Uid: 0 0 0 0
Gid: 0 0 0 0
bash$ cat /proc/$$/status | egrep 'haCap(Prm|Inh|Eff)'
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
Source du programme
/* userns_child_exec.c
Licensed under GNU General Public License v2 or later
Create a child process that executes a shell command in new
namespace(s); allow UID and GID mappings to be specified when
creating a user namespace.
*/
#define _GNU_SOURCE
#include <err.h>
#include <sched.h>
#include <unistd.h>
#include <stdint.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <signal.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
struct child_args {
char **argv; /* Command to be executed by child, with args */
int pipe_fd[2]; /* Pipe used to synchronize parent and child */
};
static int verbose;
static void
usage(char *pname)
{
fprintf(stderr, "Usage: %s [options] cmd [arg...]\n\n", pname);
fprintf(stderr, "Create a child process that executes a shell "
"command in a new user namespace,\n"
"and possibly also other new namespace(s).\n\n");
fprintf(stderr, "Options can be:\n\n");
#define fpe(str) fprintf(stderr, " %s", str);
fpe("-i New IPC namespace\n");
fpe("-m New mount namespace\n");
fpe("-n New network namespace\n");
fpe("-p New PID namespace\n");
fpe("-u New UTS namespace\n");
fpe("-U New user namespace\n");
fpe("-M uid_map Specify UID map for user namespace\n");
fpe("-G gid_map Specify GID map for user namespace\n");
fpe("-z Map user's UID and GID to 0 in user namespace\n");
fpe(" (equivalent to: -M '0 <uid> 1' -G '0 <gid> 1')\n");
fpe("-v Display verbose messages\n");
fpe("\n");
fpe("If -z, -M, or -G is specified, -U is required.\n");
fpe("It is not permitted to specify both -z and either -M or -G.\n");
fpe("\n");
fpe("Map strings for -M and -G consist of records of the form:\n");
fpe("\n");
fpe(" ID-inside-ns ID-outside-ns len\n");
fpe("\n");
fpe("A map string can contain multiple records, separated"
" by commas;\n");
fpe("the commas are replaced by newlines before writing"
" to map files.\n");
exit(EXIT_FAILURE);
}
/* Update the mapping file 'map_file', with the value provided in
'mapping', a string that defines a UID or GID mapping. A UID or
GID mapping consists of one or more newline-delimited records
of the form:
ID_inside-ns ID-outside-ns length
Requiring the user to supply a string that contains newlines is
of course inconvenient for command-line use. Thus, we permit the
use of commas to delimit records in this string, and replace them
with newlines before writing the string to the file. */
static void
update_map(char *mapping, char *map_file)
{
int fd;
size_t map_len; /* Length of 'mapping' */
/* Replace commas in mapping string with newlines. */
map_len = strlen(mapping);
for (size_t j = 0; j < map_len; j++)
if (mapping[j] == ',')
mapping[j] = '\n';
fd = open(map_file, O_RDWR);
if (fd == -1) {
fprintf(stderr, "ERROR: open %s: %s\n", map_file,
strerror(errno));
exit(EXIT_FAILURE);
}
if (write(fd, mapping, map_len) != map_len) {
fprintf(stderr, "ERROR: write %s: %s\n", map_file,
strerror(errno));
exit(EXIT_FAILURE);
}
close(fd);
}
/* Linux 3.19 made a change in the handling of setgroups(2) and
the 'gid_map' file to address a security issue. The issue
allowed *unprivileged* users to employ user namespaces in
order to drop groups. The upshot of the 3.19 changes is that
in order to update the 'gid_maps' file, use of the setgroups()
system call in this user namespace must first be disabled by
writing "deny" to one of the /proc/PID/setgroups files for
this namespace. That is the purpose of the following function. */
static void
proc_setgroups_write(pid_t child_pid, char *str)
{
char setgroups_path[PATH_MAX];
int fd;
snprintf(setgroups_path, PATH_MAX, "/proc/%jd/setgroups",
(intmax_t) child_pid);
fd = open(setgroups_path, O_RDWR);
if (fd == -1) {
/* We may be on a system that doesn't support
/proc/PID/setgroups. In that case, the file won't exist,
and the system won't impose the restrictions that Linux 3.19
added. That's fine: we don't need to do anything in order
to permit 'gid_map' to be updated.
However, if the error from open() was something other than
the ENOENT error that is expected for that case, let the
user know. */
if (errno != ENOENT)
fprintf(stderr, "ERROR: open %s: %s\n", setgroups_path,
strerror(errno));
return;
}
if (write(fd, str, strlen(str)) == -1)
fprintf(stderr, "ERROR: write %s: %s\n", setgroups_path,
strerror(errno));
close(fd);
}
static int /* Start function for cloned child */
childFunc(void *arg)
{
struct child_args *args = arg;
char ch;
/* Wait until the parent has updated the UID and GID mappings.
See the comment in main(). We wait for end of file on a
pipe that will be closed by the parent process once it has
updated the mappings. */
close(args->pipe_fd[1]); /* Close our descriptor for the write
end of the pipe so that we see EOF
when parent closes its descriptor. */
if (read(args->pipe_fd[0], &ch, 1) != 0) {
fprintf(stderr,
"Failure in child: read from pipe returned != 0\n");
exit(EXIT_FAILURE);
}
close(args->pipe_fd[0]);
/* Execute a shell command. */
printf("About to exec %s\n", args->argv[0]);
execvp(args->argv[0], args->argv);
err(EXIT_FAILURE, "execvp");
}
#define STACK_SIZE (1024 * 1024)
static char child_stack[STACK_SIZE]; /* Space for child's stack */
int
main(int argc, char *argv[])
{
int flags, opt, map_zero;
pid_t child_pid;
struct child_args args;
char *uid_map, *gid_map;
const int MAP_BUF_SIZE = 100;
char map_buf[MAP_BUF_SIZE];
char map_path[PATH_MAX];
/* Parse command-line options. The initial '+' character in
the final getopt() argument prevents GNU-style permutation
of command-line options. That's useful, since sometimes
the 'command' to be executed by this program itself
has command-line options. We don't want getopt() to treat
those as options to this program. */
flags = 0;
verbose = 0;
gid_map = NULL;
uid_map = NULL;
map_zero = 0;
while ((opt = getopt(argc, argv, "+imnpuUM:G:zv")) != -1) {
switch (opt) {
case 'i': flags |= CLONE_NEWIPC; break;
case 'm': flags |= CLONE_NEWNS; break;
case 'n': flags |= CLONE_NEWNET; break;
case 'p': flags |= CLONE_NEWPID; break;
case 'u': flags |= CLONE_NEWUTS; break;
case 'v': verbose = 1; break;
case 'z': map_zero = 1; break;
case 'M': uid_map = optarg; break;
case 'G': gid_map = optarg; break;
case 'U': flags |= CLONE_NEWUSER; break;
default: usage(argv[0]);
}
}
/* -M or -G without -U is nonsensical */
if (((uid_map != NULL || gid_map != NULL || map_zero) &&
!(flags & CLONE_NEWUSER)) ||
(map_zero && (uid_map != NULL || gid_map != NULL)))
usage(argv[0]);
args.argv = &argv[optind];
/* We use a pipe to synchronize the parent and child, in order to
ensure that the parent sets the UID and GID maps before the child
calls execve(). This ensures that the child maintains its
capabilities during the execve() in the common case where we
want to map the child's effective user ID to 0 in the new user
namespace. Without this synchronization, the child would lose
its capabilities if it performed an execve() with nonzero
user IDs (see the capabilities(7) man page for details of the
transformation of a process's capabilities during execve()). */
if (pipe(args.pipe_fd) == -1)
err(EXIT_FAILURE, "pipe");
/* Create the child in new namespace(s). */
child_pid = clone(childFunc, child_stack + STACK_SIZE,
flags | SIGCHLD, &args);
if (child_pid == -1)
err(EXIT_FAILURE, "clone");
/* Parent falls through to here. */
if (verbose)
printf("%s: PID of child created by clone() is %jd\n",
argv[0], (intmax_t) child_pid);
/* Update the UID and GID maps in the child. */
if (uid_map != NULL || map_zero) {
snprintf(map_path, PATH_MAX, "/proc/%jd/uid_map",
(intmax_t) child_pid);
if (map_zero) {
snprintf(map_buf, MAP_BUF_SIZE, "0 %jd 1",
(intmax_t) getuid());
uid_map = map_buf;
}
update_map(uid_map, map_path);
}
if (gid_map != NULL || map_zero) {
proc_setgroups_write(child_pid, "deny");
snprintf(map_path, PATH_MAX, "/proc/%jd/gid_map",
(intmax_t) child_pid);
if (map_zero) {
snprintf(map_buf, MAP_BUF_SIZE, "0 %ld 1",
(intmax_t) getgid());
gid_map = map_buf;
}
update_map(gid_map, map_path);
}
/* Close the write end of the pipe, to signal to the child that we
have updated the UID and GID maps. */
close(args.pipe_fd[1]);
if (waitpid(child_pid, NULL, 0) == -1) /* Wait for child */
err(EXIT_FAILURE, "waitpid");
if (verbose)
printf("%s: terminating\n", argv[0]);
exit(EXIT_SUCCESS);
}
VOIR AUSSI
newgidmap(1), newuidmap(1), clone(2), ptrace(2), setns(2),
unshare(2), proc(5), subgid(5), subuid(5), capabilities(7),
cgroup_namespaces(7), credentials(7), namespaces(7),
pid_namespaces(7)
Le fichier Documentation/admin-guide/namespaces/resource-control.rst des
sources du noyau.
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>,
Cédric Boutillier <cedric.boutillier@gmail.com>,
Frédéric Hantrais <fhantrais@gmail.com>
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 à
Index
- NOM
-
- DESCRIPTION
-
- Espaces de noms imbriqués, appartenance aux espaces de noms
-
- Capacités
-
- Effet des capacités à l’intérieur d’un espace de noms utilisateur
-
- Liens entre les espaces de noms utilisateur et les autres espaces de noms
-
- Correspondance des identifiants d'utilisateur et de groupe : uid_map et gid_map
-
- Création des mappages d'ID utilisateur et groupe : écriture dans uid_map et gid_map
-
- Mappages d’ID de projet : projid_map
-
- Interaction avec les appels système qui modifient les UID ou les GID
-
- The /proc/pid/setgroups file
-
- ID utilisateur et groupe non mappés
-
- Accession aux fichiers
-
- Opérations sur les capacités relatives aux fichiers
-
- Programmes set-user-ID et set-group-ID
-
- Divers
-
- STANDARDS
-
- NOTES
-
- Superutilisateur global
-
- Disponibilité
-
- EXEMPLES
-
- Source du programme
-
- VOIR AUSSI
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 05:06:39 GMT, September 19, 2025