Welche Möglichkeiten werden empfohlen, um eine Remote-*nix-Installation vor einem ungeschickten Administrator zu schützen?

Question

Hin und wieder (oft sehr lange) habe ich das Problem, dass ich einen Befehl ausführe, der eine Linux-Maschine völlig durcheinanderbringt.

Zuletzt habe ich versehentlich die Root-Partition erneut gemountet (ich dachte, es sei das neue USB-Laufwerk, das ich gerade formatiert hatte) und dann die Partition rekursiv auf mich selbst chownen lassen (wiederum nur, um mir selbst Benutzerzugriff auf das USB-Laufwerk zu gewähren). Sobald mir klar wurde, was ich getan hatte (mitten im Vorgang), habe ich es abgebrochen, aber der Schaden war angerichtet. Viele Kernprogramme gehörten nicht mehr dem Root, sodass sich die Maschine im Wesentlichen in einem zombifizierten Zustand befand. Einige Benutzerfunktionen (ssh, rsync) funktionierten noch, aber Dinge auf Verwaltungsebene waren vollständig gesperrt. Mounten, Umounten, erneutes Anfügen an Bildschirmsitzungen, Neustart usw. waren nicht möglich.

Wenn die Maschine hier bei mir im Wohnzimmer stünde, wäre es ein Kinderspiel gewesen, sie zu „reparieren“ (neu zu installieren). Aber das ist nicht der Fall. Sie steht im Haus meines Bruders. Er findet es nicht toll, wenn ich ihm bei Reparaturen/Neuinstallationen behilflich bin, und das verstehe ich. Also fahre ich in ein paar Tagen hin, um den Schaden zu beheben, den ich angerichtet habe (und hoffentlich etwas zu installieren, das gegen Admin-Fehler resistenter ist).

Ich sage das alles, um die Frage zu stellen: Welche Methoden werden empfohlen, um eine Installation gegen ungeschicktes Admin-Verhalten zu schützen?

Dinge, die nicht berücksichtigt oder berücksichtigt und schnell verworfen wurden:

1. Den Administrator abhärten, damit er keine dummen Befehle ausführt: Eine großartige Idee, aber sie funktioniert nicht, weil ich als Mensch manchmal Dinge tue, von denen ich im Nachhinein merke, dass es keine gute Idee ist. Ich versuche, mich selbst im Voraus zu überlisten, sodass die Maschine, wenn ich etwas Dummes tue, dies ablehnt und ich merke: „Oh Mist! Das hätte sehr schlimm (TM) ausgehen können! Das machen wir nicht noch einmal.“

Dinge, die ich berücksichtigt habe:

1. Mounten Sie die Root-Partition schreibgeschützt: Dies würde die Root-Partition vor Änderungen schützen, die negative Auswirkungen haben könnten, wenn Teile beschreibbar sein sollten, dies aber nicht sind. Außerdem würde die Partition nicht unbedingt davor geschützt, an einer anderen Stelle erneut schreibgeschützt gemountet zu werden.
2. Verwenden Sie ein komprimiertes, schreibgeschütztes Root-Image irgendeiner Art mit einer darüber liegenden Union-ähnlichen beschreibbaren Ebene, sodass an der Root keine Änderungen vorgenommen werden und ein Neustart alle Fehler behebt: Dies wäre in Ordnung/gut, wenn an der Root keine Änderungen vorgenommen werden müssen und /etc möglicherweise aus einer persistenten Datei an einem anderen Ort neu geladen/aufgefüllt werden könnte.
3. Verwenden Sie btrfs mit regelmäßigen (vielleicht täglichen) Snapshots, damit im Fehlerfall die Wiederherstellung einfacher ist: Ist möglicherweise immer noch nicht optimal, da ein direktes Eingreifen des Benutzers erforderlich wäre und ich nicht weiß, ob ich jemand anderen durch die Änderungen führen könnte, um das Problem rückgängig zu machen.
4. Verwenden Sie eine eher „lebendige“/„eingebettete“ Linux/BSD-Distribution, die mehr auf Stabilität/Vorhersehbarkeit/Sicherheit ausgelegt ist, statt einer eher generischen Distribution

So wie die Dinge jetzt stehen, werde ich wahrscheinlich Option 4 verwenden, um ein etwas eingeschränkteres System zu installieren als die vollständige Debian-Installation, die ich bisher verwendet habe. Aber als reiner Dateiserver und Torrent-Client sollte es gut funktionieren, und als Remote-Rechner ist es ein ziemlich großer Vorteil, den Rechner vor mir selbst zu schützen.

Answer 1

Die harte Wahrheit ist, dass Sie nichts vor Ihrer eigenen Dummheit schützen kann. Es gibt keine DWIM-Schnittstelle (do what I mean). Der Computer kann nicht zwischen Absicht und Zufall unterscheiden. Egal, wie viel Abstraktion Sie anhäufen, ein falscher Befehl kann alles zerstören.

Die einfache Antwort ist:Machen Sie langsamer und achten Sie darauf, was Sie tun.

Answer 2

Führen Sie Ihre Installation in einer virtuellen Maschine aus. Erstellen Sie einen Snapshot eines bekannten guten Zustands. Erstellen Sie Snapshots, bevor Sie etwas Riskantes tun. Tun Sie in der Hostumgebung fast nichts. Wenn Sie es vermasseln, stellen Sie eine Verbindung zur Hostumgebung her und stellen Sie den Snapshot wieder her.

Answer 3

Nichts hindert Sie daran, sich selbst ins Bein zu schießen. Sie „dachten“, die Root-Partition sei ein USB-Stick. Sie könnten eine wichtige Maschine genauso leicht mit einer Wegwerf-VM verwechseln. (Passiert den Besten von uns)

Wichtig ist, den Dienst, den Ihre Computer bereitstellen, redundant zu machen.

In diesem Fall könnten Sie zwei Linux-Versionen auf zwei separaten Partitionen installieren. Sie können Ihrem Bruder sagen, dass er die andere Partition booten soll. (Nur eine Idee)

Am wichtigsten ist, dass Sie Backups erstellen und über eine Wiederherstellungsstrategie verfügen.

Da Sie in diesem Fall die Verantwortung für den PC Ihres Bruders übernommen haben, sollten Sie kontinuierlich Sicherungskopien aller Daten erstellen und mehrere Kopien bei sich behalten.

Sie können Ihrem Bruder auch ein USB-Linux-Laufwerk zum Booten mit einem SSH-Server und einem festgelegten Passwort zur Verfügung stellen. Und stellen Sie seinen PC so ein, dass er vom USB-Stick bootet. Im Notfall bitten Sie ihn dann einfach, den USB-Stick einzustecken und den PC neu zu starten.

Answer 4

Führen Sie keine Aktionen als Root-Benutzer aus. Richten Sie sudo so ein, dass Ihr regulärer Account Root-Aufgaben ausführen kann, allerdings mit einem Passwort. So haben Sie eine letzte Chance zu sehen, was Sie wirklich tun.

Wenn Sie jedoch als Root arbeiten, richten Sie Aliase für allgemeine Befehle ein, die eine interaktive Verwendung erzwingen. Beispielsweise alias rm="rm -i"wird rmvor dem Entfernen eine Eingabeaufforderung angezeigt. Sie können dies explizit mit -f(einer bewussten Entscheidung) überschreiben, wenn Sie dies wirklich möchten rm *(wäre dann rm -f *).

Sie haben nicht gesagt, welches FS auf dem USB-Stick war. Normalerweise sind es VFAT. Sie können diese mit Optionen mounten, damit jede Datei bereits so aussieht, als gehöre sie einem bestimmten Benutzer. Dann müssen Sie sie nie ausführen chown -r ...und können so die Möglichkeit eines Fehlers ausschließen.

Färben Sie die Eingabeaufforderung Ihrer Root-Shell rot ein, um Sie daran zu erinnern, dass Sie mit erhöhten Berechtigungen arbeiten.

Erschwert Ihnen als Root im Allgemeinen die Arbeit, da Hindernisse wie Kennwortabfragen usw. auftreten.

Um das Problem zu beheben, können Sie nun nachträglich auf eine ähnliche Maschine zugreifen und diese verwenden, findum die SUID/SGID-Programme anzuzeigen. Stellen Sie dann mit dem chmodBefehl sicher, dass die beschädigte Festplatte mit dieser übereinstimmt.