10. Conteneurs privilégiés et non privilégiés

Tous les conteneurs partagent le noyau de l'hôte : la question qui se pose aussitôt est donc celle de la sécurité. Que se passe-t-il si un service compromis obtient les droits root dans le conteneur ? La réponse dépend d'un seul réglage, choisi à la création — le mode privilégié ou non privilégié.

10.1 Conteneurs privilégiés et non-privilégiés

Proxmox vous propose, à la création de chaque conteneur, de choisir entre un mode privilégié et un mode non-privilégié. Ce choix conditionne directement la posture de sécurité du conteneur et certaines de ses capacités.

Tout se joue sur les UID (User ID, numéros d'utilisateur) que le noyau attribue aux processus du conteneur. Avant de cocher ou décocher cette case, il faut comprendre ce qui se passe réellement sous le capot.

10.1.1 Ce que signifie "non-privilégié" — le remapping d'UIDs

La distinction repose sur une fonctionnalité du noyau Linux appelée user namespace. Pour comprendre pourquoi elle change tout, il faut saisir ce que fait root dans un conteneur sans elle.

Sans user namespace (conteneur privilégié), l'UID 0 à l'intérieur du conteneur correspond exactement à l'UID 0 sur l'hôte. Du point de vue du noyau Linux, c'est le même utilisateur.

Si un attaquant exploite une faille dans le conteneur et parvient à en sortir, il est immédiatement root sur la machine physique. Il a alors accès à tous les autres conteneurs, aux disques, à la configuration réseau. L'isolation LXC protège contre les accès normaux, mais une faille noyau suffit à tout compromettre.

Avec user namespace (conteneur non-privilégié), Proxmox configure un remapping d'UIDs : l'UID 0 à l'intérieur du conteneur est traduit en UID 100000 sur l'hôte. L'UID 1 devient 100001, l'UID 1000 devient 101000, et ainsi de suite sur une plage de 65 536 UIDs. Ce remapping est défini dans deux fichiers sur l'hôte :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Plages UID/GID allouées à Proxmox pour les conteneurs non-privilégiés
cat /etc/subuid
# → root:100000:65536

cat /etc/subgid
# → root:100000:65536

Résultat attendu :

root:100000:65536

Cela signifie que l'utilisateur root sur l'hôte peut utiliser la plage d'UIDs 100000–165535 pour les conteneurs non-privilégiés. Proxmox gère automatiquement cette allocation — vous n'avez jamais à modifier ces fichiers manuellement.

Concrètement : un attaquant peut obtenir les droits root à l'intérieur du conteneur (UID 0 dans le conteneur = UID 100000 sur l'hôte). Il n'est pourtant qu'un utilisateur ordinaire, sans privilèges, sur la machine physique. La faille noyau ne suffit plus.

10.1.2 Tableau de décision — quand choisir quel mode

La règle de départ est simple : toujours commencer en non-privilégié. La majorité des services courants fonctionnent parfaitement dans ce mode. Le mode privilégié n'est justifié que dans des cas précis, et encore — souvent évitables grâce aux features (voir section suivante).

10.1.3 Les features — la voie du milieu

Entre « non privilégié strict » et « privilégié total », Proxmox permet d'activer des fonctions précises sur un conteneur non privilégié, par l'option --features. On évite ainsi de sacrifier toute la sécurité du remappage pour un besoin ponctuel.

L'activer sur un conteneur déjà créé — interface : CT 200 → Options → Features → Edit → cocher Nesting → OK. En ligne de commande :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

pct set 200 --features nesting=1   # ajouter la fonction nesting
pct config 200 | grep features      # vérifier la configuration
pct reboot 200                      # redémarrer pour l'appliquer

Résultat attendu : features: nesting=1.

LXC applique les features au démarrage du conteneur : le redémarrage est obligatoire, deux à trois secondes pour un conteneur. Pour ne pas voir l'avertissement du tout, ajoutez --features nesting=1 dès la création, avec pct create.

10.1.4 Créer un conteneur dans chaque mode

La commande pct create reste identique dans les deux cas, seule la valeur de --unprivileged change :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Mode non-privilégié — à utiliser par défaut
# --unprivileged 1 : root du CT = UID 100000 sur l'hôte
pct create 200 local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst \
  --hostname ct-secure \
  --unprivileged 1 \
  --memory 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=10.44.1.50/24,gw=10.44.1.1 \
  --password dawan

# Mode privilégié — uniquement si NFS server ou accès /dev indispensable
# --unprivileged 0 : root du CT = root sur l'hôte — risque réel
pct create 300 local:vztmpl/debian-13-standard_13.6-1_amd64.tar.zst \
  --hostname ct-nfs-server \
  --unprivileged 0 \
  --memory 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=10.44.1.50/24,gw=10.44.1.1 \
  --password dawan

# Vérifier le mode d'un conteneur existant
pct config 200 | grep unprivileged

Résultat attendu :

unprivileged: 1

La valeur 1 confirme le mode non-privilégié. Sur un conteneur privilégié, la commande n'affiche rien : 0 est la valeur par défaut, et Proxmox n'écrit pas dans la configuration une option laissée à sa valeur par défaut. Un grep muet n'est donc pas une erreur, c'est la réponse « privilégié ».

À retenir : un conteneur non privilégié décale ses UID : le root du conteneur est un utilisateur sans droit sur l'hôte (/etc/subuid). C'est le choix par défaut et la règle en production. nesting et fuse ajoutent des capacités sans passer en privilégié.