Warum erlaubt Linux 'init = / bin / bash'?

Ich habe kürzlich herausgefunden, dass ich, wenn ich GRUB vor dem Booten bearbeite und ich füge hinzu rw init=/bin/bash, eine Root-Shell bekomme.

Da ich in einem Zustand bin, in dem ich alles verstehen möchte, möchte ich wissen, warum dies geschieht. Ich meine, ist es ein Fehler? Ist es ein Feature? Ist es da, um Administratoren bei der Behebung von Problemen zu helfen, da dies nur funktioniert, wenn Sie physischen Zugriff auf einen Computer haben?

Wird es von GRUB oder dem eigentlichen Kernel bereitgestellt?

Dies ist eine Funktion, die für die Systemwartung verwendet wird: Sie ermöglicht es einem Systemadministrator, ein System aus fehlerhaften Initialisierungsdateien wiederherzustellen oder ein vergessenes Kennwort zu ändern.

Dieser Beitrag in der Red Hat-Mailingliste erklärt einige Dinge:

In Unix-ähnlichen Systemen ist init der erste auszuführende Prozess und der ultimative Vorläufer aller Prozesse, die jemals ausgeführt wurden. Es ist für die Ausführung aller Init-Skripte verantwortlich.

Sie weisen den Linux-Kernel an, / bin / bash als init und nicht als Systeminit auszuführen. [...]

Sie nutzen also nichts aus, sondern verwenden lediglich eine Standard-Kernelfunktion.

Wie in einem Kommentar vermerkt, ist das rwFlag von getrennt init=. Es weist das System lediglich an, das Root-Dateisystem als Lese- / Schreibzugriff bereitzustellen (damit Sie z. B. die falsch konfigurierte Datei bearbeiten oder ein Kennwort ändern können).

Ihr System verfügt über Mechanismen zum Ausführen und Debuggen (wie der Parameter init) und möglicherweise über Sicherheitsmechanismen, um zu verhindern, dass unerwünschte Benutzer diese ausnutzen. Dies sind Funktionen, keine Fehler.

Der Bootloader ist für das Starten des Betriebssystems verantwortlich. Die Sicherheit des Betriebssystems ist zu diesem Zeitpunkt offensichtlich nicht zutreffend. Sie könnten einfach einen anderen Kernel, initrd, root fs laden oder andere Optionen einstellen (wie init path). Wenn Sie Benutzer daran hindern möchten, muss dies über den Bootloader erfolgen.

Ihr System (wahrscheinlich ein PC, also BIOS) lädt den Bootloader und daher gilt die Bootloader-Sicherheit offensichtlich nicht für dieses System. Wenn Sie verhindern möchten, dass Benutzer das BIOS von einem USB-Stick oder ähnlichem booten, müssen Sie dies auf dieser Ebene tun.

Ihr System befindet sich möglicherweise irgendwo auf einem Schreibtisch. Wenn Sie Benutzer daran hindern möchten, den Kopierer zu öffnen und die Festplatte gegen eine eigene auszutauschen oder das Laufwerk zu entfernen, um es in ihre Computer einzubinden, müssen Sie dies auf physischer Ebene tun. Und es wird sie nicht davon abhalten, den ganzen Schreibtisch aufzuheben und in ihrem Fluchtwagen davonzufahren ...

So ist Sicherheit. Elefanten den ganzen Weg hinunter.

Wenn der Computer gestartet wird, wird ein Programm namens "init" ausgeführt, das normalerweise bei /bin/initoder zu finden ist /sbin/init. Dieses Programm ist für den gesamten Systemstart und die Erstellung einer benutzerfreundlichen Umgebung verantwortlich.

Durch die Angabe init=/bin/bashwird der Kernel angewiesen , /bin/bashstattdessen auszuführen (dies ist eine Shell). Durch die Angabe rwwird der Kernel angewiesen , mit der Festplatte im Lese- / Schreibmodus anstatt im schreibgeschützten Modus zu starten. Üblicherweise startet der Kernel mit der Festplatte im Nur-Lese-Modus, und ein späterer Prozess überprüft die Integrität der Festplatte, bevor auf Lese- / Schreibzugriff umgeschaltet wird.

Zusammengesetzt von 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

Dies ist ein Feature des Kernels: Es ermöglicht seinem "Aufrufer", dh dem Bootloader, große Flexibilität. Grub bietet Ihnen die Möglichkeit, diese Flexibilität beim Booten zu nutzen, bietet Ihnen jedoch auch die Möglichkeit, diese Art von Manipulation einzuschränken . Dies ist insbesondere in den Fällen sinnvoll, in denen nicht autorisierte Benutzer möglicherweise Zugriff auf den Startvorgang erhalten, ansonsten jedoch der Zugriff auf die Festplatte selbst verweigert wird.

init=kann jede ausführbare Datei nehmen

init=Kann jede ausführbare Datei, einschließlich Shell-Skripten, aufnehmen .

Hier zeige ich zum Beispiel, wie man ein beliebiges minimales C kompiliert init: Wie man eine benutzerdefinierte Linux-Distribution erstellt, die nur ein Programm und nichts anderes ausführt?

Warum sollte es ausgerechnet nicht akzeptieren /bin/bash, dass es sich um eine reguläre ausführbare Datei handelt, die tatsächlich nützlich sein kann? :-)

Als nächstes sollten Sie auch versuchen zu verstehen, wie die Kompromisse mit Ihren Stammkunden initwie systemd oder Busybox aussehen werden.

Grundsätzlich mit einem rohen /bin/bash, Sie:

• die Möglichkeit verlieren, die Anmeldung mit Passwörtern zu kontrollieren. Dies ist jedoch manchmal wünschenswert, z. B. bei der Systememulation: Wie kann man sich automatisch anmelden, ohne den Root-Benutzernamen oder das Passwort in Buildroot BusyBox init einzugeben?
• die Kontrolle über den Job verlieren, zB Strg + C wird nicht funktionieren
• Wenn Sie Strg + C drücken, wird die Shell beendet, und die Kernel-Panics sind seitdem initvorhanden

Die Job-Kontrolle kann auf Busybox 'init und anderen ähnlichen Inits mit einem führenden -in der wiederhergestellt werden inittab:

tty3::respawn:-/bin/sh

Die normaleren inittabEinträge, bei denen die Anmeldung verwendet wird und bei denen weiterhin Shells angezeigt werden, wenn Sie Strg + D ausführen, sind:

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

die die gettyausführbare Datei verwenden, aber TODO: Ich konnte diese nicht selbst ohne die Busybox erzeugeninit : getty von der Kommandozeile aus starten?

Sie können dieses Setup verwenden , um damit herumzuspielen und die obigen Schlussfolgerungen zu ziehen.