J'ai récemment découvert que si je modifie GRUB avant de démarrer et que j'ajoute rw init=/bin/bash
Je 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-il là pour aider les administrateurs à réparer les choses car cela ne fonctionne que si vous avez un accès physique à un ordinateur?
Est-il fourni par GRUB ou le noyau réel?
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 foirés ou de modifier un mot de passe oublié.
Ce message dans la liste de diffusion Red Hat explique certaines choses:
Dans les systèmes de type Unix, init est le premier processus à exécuter 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 l'initialisation du système. [...]
Ainsi, vous n'exploitez rien, vous utilisez simplement une fonctionnalité de noyau standard.
De plus, comme indiqué dans un commentaire, le drapeau rw
est distinct de init=
, il indique simplement au système de monter le système de fichiers racine en lecture-écriture (afin que vous puissiez par exemple modifier le fichier mal configuré ou changer un mot de passe).
Votre système dispose de mécanismes d'exécution et de débogage (comme le paramètre init) et il dispose probablement de mécanismes de sécurité pour empêcher les utilisateurs indésirables d'en tirer parti. 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 le chemin init). Si vous souhaitez empêcher les utilisateurs de le faire, cela doit être fait 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 de démarrage ne s'applique pas à lui. Si vous voulez empêcher les utilisateurs de démarrer le BIOS à partir de l'USB ou autre, vous devez le faire à ce niveau.
Votre système est peut-être sur un bureau quelque part. Si vous voulez empêcher les utilisateurs d'ouvrir le coputer et de changer le disque dur pour l'un des leurs ou de retirer le lecteur pour le monter dans leurs machines, vous devez le faire au niveau physique. Et cela ne les empêchera pas de prendre tout le bureau et de partir dans leur fourgonnette ...
C'est comme ça que la sécurité est. Des éléphants tout en bas.
Lorsque l'ordinateur démarre, il exécute un programme appelé "init", généralement trouvé dans /bin/init
ou /sbin/init
. Ce programme est responsable de tout le démarrage du système et de la création d'un environnement utilisable.
En précisant init=/bin/bash
indique au noyau d'exécuter /bin/bash
à la place (qui est un Shell). La spécification de rw
indique au noyau de démarrer avec le disque dur en mode lecture-écriture au lieu du mode lecture seule. Traditionnellement, le noyau démarre avec le disque en mode lecture seule et un processus vérifie plus tard l'intégrité du disque avant de passer en lecture-écriture.
Composé à partir 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 fonctionnalité du noyau: elle permet à son "appelant", c'est-à-dire le chargeur de démarrage, une grande flexibilité. Grub vous fournit les moyens d'utiliser cette flexibilité lors du démarrage, mais il vous fournit également les moyens de restreindre ce type de falsification . Cela est particulièrement logique dans les cas où des utilisateurs non autorisés peuvent mettre la main sur 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 scripts Shell .
Ici, par exemple, je montre comment créer un C arbitraire minimal compilé init
: Comment créer une distribution Linux personnalisée qui exécute un seul programme et rien d'autre?
Alors pourquoi voudrait-il pas accepter /bin/bash
, De toutes choses, qui est juste un exécutable normal, et peut en fait être utile? :-)
Ensuite, vous devriez également essayer de comprendre quels seront les compromis avec votre init
régulier comme systemd ou Busybox '
En gros, avec un /bin/bash
Brut, vous:
init
existaitLe contrôle des travaux peut être restauré sur l'initialisation de Busybox et d'autres initiales similaires avec un -
Dans le inittab
:
tty3::respawn:-/bin/sh
Les entrées inittab
les plus normales, qui utilisent la connexion et continuent de générer des shells si vous faites Ctrl + D sont:
::respawn:/sbin/getty -L ttyS0 0 vt100
qui utilisent l'exécutable getty
, mais TODO: Je n'ai pas pu les générer moi-même sans Busybox init
: Getty start from command line?
Vous pouvez utiliser cette configuration pour jouer avec et atteindre les conclusions ci-dessus.