init=/bin/bash : ce que protège vraiment le login Linux

Le raccourci circule parfois comme une « élévation de privilèges Linux » : ajouter init=/bin/bash au démarrage, obtenir #. Présenté ainsi, il manque le plus important. Cette méthode suppose le contrôle du démarrage, hors de portée d’un shell utilisateur ordinaire. Elle commence au menu d’amorçage, avec la capacité d’en modifier les arguments, et ne donne accès à la racine du système que si le volume est disponible. Elle met en évidence la frontière entre le mot de passe d’une session Linux, le contrôle du démarrage et la protection des données au repos.

Le noyau Linux documente init= comme le chemin du programme à lancer au lieu de /sbin/init. Si la chaîne de démarrage le respecte, init=/bin/bash fait de Bash le premier processus de l’espace utilisateur sur la racine finale. Le noyau lance ce processus avec les privilèges nécessaires à l’initialisation : le prompt obtenu est root sans avoir franchi l’écran de connexion. La condition cachée est précisément « si la chaîne de démarrage le respecte ». Une distribution peut interposer un initramfs, interpréter différemment les arguments ou refuser le scénario ; le comportement doit être observé sur la machine concernée.

L’accès au menu précède l’accès à root

Avant de regarder la commande, regardons la position de l’opérateur. Il lui faut une console de démarrage, qu’il s’agisse d’un clavier local, d’une console de VM ou d’une console hors bande exposant le chargeur. Il doit aussi pouvoir éditer l’entrée du noyau. Un accès SSH à une session déjà démarrée ne donne pas ce contrôle. Un utilisateur non privilégié ne peut pas simplement écrire init=/bin/bash dans son terminal et réexécuter PID 1. Le paramètre est lu pendant un nouveau démarrage.

Sur une installation GRUB qui autorise l’édition, e ouvre l’entrée sélectionnée ; on ajoute le paramètre à la ligne qui charge le noyau, puis on lance cette entrée modifiée. Red Hat décrit l’édition temporaire avec e et Ctrl+x dans ses procédures de récupération. C’est une modification pour ce boot, pas une réécriture permanente de la configuration GRUB. Le libellé exact de la ligne (linux, linuxefi, etc.) et les touches peuvent changer avec le chargeur et la distribution.

La racine doit ensuite être accessible. Sur un disque non chiffré, l’initramfs peut monter le volume puis passer la main au programme choisi. La documentation de switch_root explicite ce passage de la racine initiale à la racine réelle et au nouvel init. Avec LUKS, l’opérateur devra normalement connaître le secret de déverrouillage ou bénéficier d’un mécanisme de déverrouillage déjà autorisé. Une politique liée aux mesures TPM peut refuser de déverrouiller après modification de la ligne de commande. La documentation Ubuntu sur le chiffrement décrit ces modèles. Voir un shell dans l’initramfs ne signifie pas que le volume chiffré contenant /etc, les données et les secrets a été monté.

Enfin, le chargeur peut demander un mot de passe pour éditer les entrées. Les procédures de protection GRUB de Red Hat distinguent l’édition protégée du simple démarrage d’une entrée existante. Un mot de passe de GRUB n’est pas un substitut au chiffrement si l’adversaire peut démarrer un autre support et lire le disque non chiffré. À l’inverse, Secure Boot seul vérifie des éléments de la chaîne de démarrage selon la configuration ; il ne faut pas en déduire qu’il interdit forcément l’édition de chaque argument du noyau. Le contrôle pertinent est la politique effective d’édition, et, pour protéger les données, la manière dont le déverrouillage du disque est lié à cette chaîne.

Un essai de VM qui répond à une seule question

Voici un essai à réaliser sur une VM que vous possédez, pas le compte rendu d’un test rootzero déjà effectué. Prenez un snapshot d’une distribution Linux avec une console GRUB accessible et une racine non chiffrée. Notez d’abord sa version, le chargeur et le mode de chiffrement. Arrêtez la VM, ouvrez son menu au démarrage, éditez uniquement l’entrée courante et ajoutez init=/bin/bash à la ligne du noyau. Démarrez cette entrée temporaire.

Si Bash s’affiche, ne confondez pas l’apparence du prompt avec une preuve. Lisez l’identité et le chemin de démarrage :

id -u
cat /proc/cmdline
readlink /proc/1/exe
findmnt -no SOURCE,OPTIONS /

Le résultat attendu, sur une VM où ce chemin fonctionne, est 0 pour l’UID, init=/bin/bash dans la ligne de commande, /bin/bash (ou sa cible réelle) pour le processus 1, et un montage racine souvent en lecture seule. Certaines images n’ont pas encore monté /proc ou n’incluent pas findmnt dans l’environnement atteint ; l’absence de ces commandes n’invalide ni ne prouve à elle seule le résultat. Lisez ce qui est effectivement disponible. Ne touchez pas à /etc/shadow : id -u et le processus 1 suffisent à établir le point pédagogique, sans modifier un compte.

On voit souvent mount -o remount,rw / dans les recettes de réinitialisation de mot de passe. Ce remount donne une capacité d’écriture si la racine est déjà montée et si son système de fichiers le permet ; il change donc la nature de l’essai. Pour ce tutoriel, laissez le volume en lecture seule. Évitez aussi exit : faire terminer le PID 1 peut provoquer un panic du noyau. Arrêtez ou réinitialisez la VM depuis l’hyperviseur, redémarrez l’entrée normale sans paramètre, puis revenez au snapshot si vous voulez un état strictement identique.

Un échec est instructif s’il est décrit exactement. Menu GRUB verrouillé ? Le contrôle a arrêté la modification de l’entrée. Invite LUKS sans secret ? Le volume est resté fermé. Shell précoce mais racine réelle absente ? Vous êtes encore dans l’initramfs. Le bureau démarre normalement ? La chaîne a pu ignorer ou remplacer le paramètre. Sur RHEL, rd.break est une autre méthode de récupération documentée : elle arrête l’initramfs avant le passage à la racine finale, alors que init=/bin/bash désigne le programme d’initialisation à lancer. (Procédure Red Hat)

Protéger la console et la chaîne de démarrage

Un mot de passe utilisateur répond à « qui ouvre une session sur ce système démarré ? ». Il ne répond pas à « qui choisit ce que le noyau va lancer avant les sessions ? ». Pour un poste exposé à un accès physique ou à une console de gestion, la défense se raisonne donc en couches : limiter et auditer l’accès à cette console, protéger l’édition du chargeur, contrôler les supports amorçables, chiffrer les volumes sensibles et vérifier le modèle de déverrouillage. Sur une VM de production, la console de l’hyperviseur est elle aussi un pouvoir d’administration à gouverner.

Le compte rendu de l’essai doit préciser la distribution, le chargeur, l’initramfs, le chiffrement, l’état de GRUB, l’argument exact, l’UID observé et le montage de /. Ces informations permettent de reproduire le résultat et d’identifier le contrôle à modifier.