
rw init=/bin/bash
Ich habe kürzlich herausgefunden, dass ich eine Root-Shell erhalte, wenn ich GRUB vor dem Booten bearbeite und hinzufüge .
Da ich in einer Situation bin, in der ich alles verstehen möchte, würde ich gerne wissen, warum das passiert. Ich meine, ist das ein Fehler? Ist das eine Funktion? Ist es dazu da, Administratoren bei der Behebung von Problemen zu helfen, da es nur funktioniert, wenn Sie physischen Zugriff auf einen Computer haben?
Wird es von GRUB oder dem eigentlichen Kernel bereitgestellt?
Antwort1
Dies ist eine Funktion, die zur Systemwartung verwendet wird: Sie ermöglicht einem Systemadministrator, ein System anhand beschädigter Initialisierungsdateien wiederherzustellen oder ein vergessenes Kennwort zu ändern.
Dieser Beitrag in der Red Hat Mailinglisteerklärt einige Dinge:
In Unix-ähnlichen Systemen ist init der erste ausgeführte Prozess und der ultimative Vorfahre aller jemals ausgeführten Prozesse. Er ist für die Ausführung aller Init-Skripte verantwortlich.
Sie weisen den Linux-Kernel an, /bin/bash als Init auszuführen, statt des System-Init. [...]
Sie nutzen also nichts aus, sondern verwenden lediglich eine Standardfunktion des Kernels.
rw
Außerdem ist das Flag , wie in einem Kommentar angemerkt, von getrennt init=
; es weist das System lediglich an, das Root-Dateisystem lese- und schreibgeschützt bereitzustellen (damit Sie beispielsweise die falsch konfigurierte Datei bearbeiten oder ein Kennwort ändern können).
Antwort2
Ihr System verfügt über Mechanismen zum Ausführen und Debuggen (wie den Init-Parameter) und wahrscheinlich auch über Sicherheitsmechanismen, die verhindern, dass unerwünschte Benutzer diese ausnutzen. Dies sind Funktionen, keine Bugs.
Der Bootloader ist für das Starten des Betriebssystems verantwortlich. Die Betriebssystemsicherheit gilt an dieser Stelle offensichtlich nicht. Sie könnten einfach einen anderen Kernel, Initrd, Root-FS laden oder andere Optionen festlegen (wie den Init-Pfad). Wenn Sie Benutzer daran hindern möchten, muss dies beim Bootloader erfolgen.
Ihr System (wahrscheinlich ein PC, also BIOS) lädt den Bootloader und daher gilt die Bootloader-Sicherheit offensichtlich nicht dafür. Wenn Sie verhindern möchten, dass Benutzer das BIOS von USB oder Ähnlichem booten, müssen Sie dies auf dieser Ebene tun.
Ihr System steht möglicherweise irgendwo auf einem Schreibtisch. Wenn Sie verhindern möchten, dass Benutzer den Computer öffnen und die Festplatte gegen eine eigene austauschen oder das Laufwerk entfernen, um es in ihren Computer einzubauen, müssen Sie dies auf physischer Ebene tun. Und es wird sie nicht davon abhalten, den ganzen Schreibtisch hochzuheben und in ihrem Fluchtwagen wegzufahren ...
So ist das mit der Sicherheit. Elefanten bis ganz nach unten.
Antwort3
So wurde der Kernel einfach konzipiert. Es mussetwasbeim Starten des Computers ausgeführt werden soll. Es gibt zwar eine Standardeinstellung, diese können Sie jedoch über die Kernel-Befehlszeile ändern.
Normalerweise wird ein Programm namens „init“ ausgeführt, das sich normalerweise unter /bin/init
oder befindet /sbin/init
. Dieses Programm ist für den gesamten Systemstart und die Erstellung einer nutzbaren Umgebung verantwortlich.
Durch die Angabe init=/bin/bash
wird stattdessen der Kernel ausgeführt /bin/bash
(was eine Shell ist). Durch die Angabe rw
wird der Kernel angewiesen, mit der Festplatte im Lese-/Schreibmodus statt im Nur-Lese-Modus zu booten. Traditionell startet der Kernel mit der Festplatte im Nur-Lese-Modus und ein späterer Prozess überprüft die Integrität der Festplatte, bevor er in den Lese-/Schreibmodus wechselt.
Antwort4
init=
kann nehmenbeliebigausführbar
init=
kann jede ausführbare Datei annehmen, einschließlichShell-SkripteDer Grund hierfür ist wahrscheinlich, dass dieexec
Syscall kann sowohl ELF-Programme als auch Shebangs direkt verarbeiten.
Hier zeige ich als Beispiel, wie man eine beliebige minimale C-Kompilierung erstellt init
:Wie erstelle ich eine benutzerdefinierte Linux-Distribution, die nur ein Programm und sonst nichts ausführt?
Warum also sollte esnicht/bin/bash
ausgerechnet accept , was doch nur eine normale ausführbare Datei ist und tatsächlich nützlich sein kann? :-)
Als nächstes sollten Sie auch versuchen zu verstehen, was die Kompromisse mit Ihrem regulären init
wie systemd oder Busybox sein werden.
Mit einem Raw können /bin/bash
Sie grundsätzlich Folgendes tun:
- die Möglichkeit verlieren, die Anmeldung mit Passwörtern zu kontrollieren. Dies ist aber manchmal erwünscht, z. B. bei der Systememulation:Wie kann ich mich automatisch anmelden, ohne den Root-Benutzernamen oder das Root-Passwort in Buildroot BusyBox init einzugeben?
- verlieren Sie die Kontrolle über den Job, z. B. funktioniert Strg + C nicht
- Wenn Sie Strg+C drücken, wird die Shell beendet und der Kernel gerät in Panik, da
init
er
Die Jobkontrolle kann bei Busybox-Init und anderen ähnlichen Inits mit einem führenden -
in wiederhergestellt werden inittab
:
tty3::respawn:-/bin/sh
Die normaleren inittab
Einträge, die die Anmeldung verwenden und weiterhin Shells erzeugen, wenn Sie Strg+D drücken, sind:
::respawn:/sbin/getty -L ttyS0 0 vt100
die die ausführbare Datei verwenden getty
, aber TODO: Ich konnte diese ohne die Busybox nicht selbst erzeugen init
:Getty von der Befehlszeile aus starten?
Sie könnendieses Setupum damit herumzuspielen und zu den oben genannten Schlussfolgerungen zu gelangen.