Sous Linux, le compte « root » est-il puissant à cause de son nom ?

Beaucoup répondent par réflexe : « root est le compte administrateur. » L'enjeu est de savoir ce que le noyau utilise réellement pour décider qui est privilégié.

Le noyau vérifie l'UID, pas le nom

La page de manuel des capabilities décrit le modèle UNIX traditionnel : les processus privilégiés sont ceux dont l'identifiant utilisateur effectif est 0 (le superutilisateur, ou root), et les processus non privilégiés ont un UID effectif non nul. Le nom root n'est qu'une étiquette dans /etc/passwd associée à ce numéro. Si vous ajoutez une seconde entrée d'UID 0 — par exemple toor ou backup — ce compte est lui aussi un superutilisateur complet.

Pourquoi les défenseurs s'y intéressent

Un attaquant qui modifie /etc/passwd pour ajouter un compte d'UID 0 obtient root sans toucher au mot de passe de root ni à la configuration sudo. Rechercher toute entrée d'UID 0 autre que root est donc un contrôle de persistance de base, présent dans les listes de durcissement et de chasse.

Root n'est plus du tout-ou-rien

Depuis Linux 2.2, les privilèges traditionnellement liés au superutilisateur sont répartis en unités distinctes appelées capabilities, activables et désactivables indépendamment. Par exemple, CAP_DAC_OVERRIDE contourne les contrôles de permission en lecture, écriture et exécution des fichiers. Un service peut recevoir uniquement la capability dont il a besoin au lieu de tourner en root complet.

Pourquoi les distracteurs échouent

• « À cause du nom » et « à cause de /root » sont des explications populaires : le noyau ne les consulte jamais.
• « À cause du shell » confond le programme de connexion et le modèle de permissions ; le shell n'a aucun effet sur le privilège.

Ce que veulent les recruteurs

« Le privilège est lié à l'UID effectif 0, pas au nom », puis la suite logique : auditer les UID 0 supplémentaires et préférer les capabilities à root complet.