Pourquoi Linux autorise-t-il 'init = / bin / bash'?

J'ai récemment découvert que si j'édite GRUB avant de démarrer et que j'ajoute, rw init=/bin/bashje me retrouve avec un shell root.

Étant dans un état où je veux tout comprendre, j'aimerais savoir pourquoi cela se produit. Je veux dire est-ce un bug? est-ce une fonctionnalité? est-ce là pour aider les administrateurs à résoudre les problèmes, car cela ne fonctionne que si vous avez un accès physique à un ordinateur?

Est-ce fourni par GRUB ou le noyau actuel?

Il s'agit d'une fonctionnalité utilisée pour la maintenance du système: elle permet à un administrateur système de récupérer un système à partir de fichiers d'initialisation corrompus ou de modifier un mot de passe oublié.

Ce message de la liste de diffusion Red Hat explique certaines choses:

Dans les systèmes de type Unix, init est le premier processus à être exécuté et l'ancêtre ultime de tous les processus jamais exécutés. Il est responsable de l'exécution de tous les scripts d'initialisation.

Vous dites au noyau Linux d’exécuter / bin / bash en tant qu’init, plutôt que d’initialisation système. [...]

Ainsi, vous n'exploitez rien, vous utilisez simplement une fonctionnalité du noyau standard.

De plus, comme indiqué dans un commentaire, l' rwindicateur est distinct de init=, il indique simplement au système de monter le système de fichiers racine en lecture-écriture (vous pouvez par exemple modifier le fichier mal configuré ou modifier un mot de passe).

Votre système dispose de mécanismes d’exécution et de débogage (comme le paramètre init), ainsi que de mécanismes de sécurité permettant d’empêcher les utilisateurs indésirables de les exploiter. Ce sont des fonctionnalités, pas des bugs.

Le chargeur de démarrage est responsable du démarrage du système d'exploitation. La sécurité du système d'exploitation ne s'applique évidemment pas à ce stade. Vous pouvez simplement charger un noyau différent, initrd, root fs ou définir différentes options (comme init path). Si vous souhaitez empêcher les utilisateurs de le faire, vous devez le faire au niveau du chargeur de démarrage.

Votre système (probablement un PC, donc le BIOS) charge le chargeur de démarrage et donc, évidemment, la sécurité du chargeur ne s'applique pas à celui-ci. Si vous souhaitez empêcher les utilisateurs de faire démarrer le bios à partir d'une clé USB, vous devez le faire à ce niveau.

Votre système peut être sur un bureau quelque part. Si vous souhaitez empêcher les utilisateurs d'ouvrir l'ordinateur et de changer le disque dur pour l'un des leurs ou de retirer le disque pour le monter sur leur ordinateur, vous devez le faire au niveau physique. Et cela ne les empêchera pas de ramasser tout le bureau et de partir dans leur van ...

C'est comme ça que la sécurité est. Les éléphants tout en bas.

Lorsque l'ordinateur démarre, il exécute un programme appelé "init", généralement trouvé à /bin/initou /sbin/init. Ce programme est responsable de tout le démarrage du système et de la création d’un environnement utilisable.

La spécification init=/bin/bashindique au noyau de s'exécuter à la /bin/bashplace (ce qui est un shell). Spécifier rwindique au noyau de démarrer avec le disque dur en mode lecture-écriture au lieu du mode lecture seule. Traditionnellement, le noyau commence avec le disque en mode lecture seule et un processus vérifie ensuite l'intégrité du disque avant de passer en lecture-écriture.

Recoupé de kernel.org :

KNL     Is a kernel start-up parameter.

init=   [KNL]
        Format: <full_path>
        Run specified binary instead of /sbin/init as init
        process.

rw      [KNL] Mount root device read-write on boot

C'est une caractéristique du noyau: elle permet à son "appelant", c'est-à-dire le chargeur de démarrage, une grande flexibilité. Grub vous donne les moyens d'utiliser cette flexibilité lors du démarrage, mais vous permet également de limiter ce type de falsification . Cela est particulièrement utile dans les cas où des utilisateurs non autorisés peuvent se procurer le processus de démarrage, mais se voient autrement refuser l'accès au disque dur lui-même.

init=peut prendre n'importe quel exécutable

init=peut prendre n’importe quel exécutable, y compris les scripts shell .

Ici, par exemple, je montre comment créer une compilation arbitraire en C minimal init: Comment créer une distribution Linux personnalisée n’exécutant qu’un programme et rien d’autre?

Alors , pourquoi ne serait - il pas accepter /bin/bash, de toutes les choses, ce qui est juste un exécutable régulier, et peut effectivement être utile? :-)

Ensuite, vous devriez également essayer de comprendre quels seront les compromis avec vos initclients habituels, tels que systemd ou Busybox.

En gros, avec un brut /bin/bash, vous:

• perdre la capacité de contrôler la connexion avec des mots de passe. Mais cela est parfois souhaitable, par exemple lors de l’émulation de système: Comment se connecter automatiquement sans taper le nom d’utilisateur ou le mot de passe root dans Buildroot BusyBox init?
• perdre le contrôle du travail, par exemple, Ctrl + C ne fonctionnera pas
• si vous faites Ctrl + C, le shell se ferme, et le noyau panique depuis qu'il initexiste

Le contrôle du travail peut être restauré sur init Busybox 'et d'autres entrées similaires avec une avance -dans le inittab:

tty3::respawn:-/bin/sh

Les inittabentrées les plus normales , qui utilisent login et gardent les shells générés si vous faites Ctrl + D sont:

::respawn:/sbin/getty -L ttyS0 0 vt100

qui utilisent l' gettyexécutable, mais TODO: Je n'ai pas été en mesure de les générer moi-même sans la Busybox init: getty start depuis la ligne de commande?

Vous pouvez utiliser cette configuration pour jouer avec et atteindre les conclusions ci-dessus.