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

51

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?

combattant
la source
12
Si vous voulez "réparer" ceci, verrouillez GRUB et votre BIOS avec un mot de passe et mettez votre disque dur en premier dans l'ordre de démarrage. Si quelqu'un d'autre a un accès physique et peut mettre le disque dur (non crypté) dans un autre ordinateur, vous avez tout de même perdu
jofel

Réponses:

44

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).

Renan
la source
2
En outre, rwest complètement séparé de init=. Le premier indique simplement au noyau de monter le système de fichiers racine en lecture-écriture.
Alexios
19

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.

XTL
la source
Beau résumé. Peut-être voudrez-vous ajouter le cryptage disque dur à cela, comme une réponse possible contre le fourgon.
MvG
11

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.

tylerl
la source
6

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
Philip Durbin
la source
1

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.

MvG
la source
1

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:

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.

Ciro Santilli 改造 中心 六四 事件
la source