System mit overlayroot vollständig gegen Veränderung schützen (Kiosk-Modus)

[S_O]

Hallo,
ich möchte gerne ein System aufsetzen, auf dem der normale Nutzer zwar alle Rechte hat, aber keine Änderung permanent ist, also mit einem Neustart vergessen.
Meine Idee: root-Dateisystem mit Overlayroot schützen, zwei Bootoptionen mit GRUB, eine mit Overlayroot (ohne Passwort) und eine, bei der Overlayroot abgeschaltet ist (passwortgeschützt). Soweit so gut, da finde ich noch Guides die erklären wie man das macht, aber mein Gedanke:

dd if=/dev/zero of=/dev/sda

Ich denke dagegen hilft auch kein Overlayroot. Gibt es eine Option die ich dem Kernel beim Booten übergeben kann, die direkten Schreibzugriff (also außerhalb der Kernel-Prozesse) auf ein Blockgerät verbietet? Oder eine andere Möglichkeit wie das geht? Damit niemand auf die Idee kommen kann einen neuen Bootloader oder so zu installieren?

Vielen Dank
Stefan

[BetterWorld]

Das kannst du leicht mit Docker erreichen. Einfach immer nur das Image neu starten und davor den jeweiligen Container löschen.
Mit "echter" Virtualisierung kannst du sowas auch nachbilden.

Auf einem bare metal wirst du Probleme haben.
Da wäre wohl ein direktes Starten aus dem UEFI mit SecureBoot möglich, was jedoch das rumschreiben auf den Platten noch immer nicht unterbindet. Vor allem nicht, wenn der User einfach Rootrechte kriegt.
Es gibt zwar Möglichkeiten sowas tief in den Innereien der Festplatten zu verstecken, aber das ist ohne weitere (und sehr geheime) Herstellerdaten/tools nicht ohne weiteres möglich.
Du könntest auch das Ding generell via Netzwerk booten, die lokalen Platten dabei überprüfen und ggf. zurücksetzen und dann dorthin chrooten.

So wirklich verstehe ich den Sinn des Ganzen eh nicht.
Entweder der User hat alle Rechte, dann ist er Root.
Oder seine Rechte sind eingeschränkt, dann ist er User.
Und mit diesem herkömmlichen Ansatz, kannst du noch immer jedes Szenario abdecken.

Was willst du wirklich?

[florian0285]

Es gibt auf Hardwareebene Write-Blocker. Da ich das nur von früher aus dem Forensic-Bereich kenne war das eine kostspielige Angelegenheit. Vielleicht sind die jetzt günstiger geworden. Es gäbe dann noch für HDD's write-protect.

Alternativ kannst du auch als 2nd-Boot-Device z. B. PXE einrichten, der dir ein blanko-image drüber bügelt. Im Image müsstest du dann im Boot-/Shutdownprozess Grub killen, damit beim nächsten boot wieder PXE startet. Das kannst du genauso auf eine Recovery DVD oder einen Stick mit write-protect packen. Entweder selbst erstellt oder mit Clonezilla und der Recovery-Option ohne Bestätigung. Vom Stick dauert das ca. 5 Minuten. Ist natürlich von der Größe und Übertragungsgeschwindigkeit abhängig.

[marce]

Kommt ein wenig auf die konkreten Anforderungen und die bestehende Hardware an - am einfachsten und schnellsten (auch für die Pflege) dürfte es sein, einen kleinen Hypervisor auf das Ding zu packen und eine einzelne VM zu starten - die kann man entsprechend absichern, recovern, pflegen und verliert auch nicht Unmengen an Ressourcen.

Alternative Lösngen über direkt lokale Images booten, irgendwelche Write-Blocker, ... würde ich nur versuchen, wenn obige einfache Methode nicht machbar ist - für einface Systempflege auf einem Single-System scheinen mir die alle zu aufwändig und zu komplex.

[florian0285]

Wie gesagt Write-Blocker könnten teuer sein, aber sie erfüllen ihren Zweck.

Write Protect für HDD's gibts in unterschiedlichen Varianten. Mir wär da die Geschichte im BIOS eingefallen, das ist nicht aufwändig sondern nur ein On/Off Schalter. Was ich auch noch kenne bzw kannte war ein Write-Protect via Jumper auf SCSI Platten. Software technisch kann man das auch über ein entsprechendes Kernel Modul regeln, dass kein Schreibzugriff ermöglicht. Ob das aber mit der Kernelentwicklung mitgewandert ist weiß ich nicht.

Ob VM via Hypervisor oder Image vom Stick ist zwar eine Zweck bezogene Sache, aber beides mit geringen Aufwand umzusetzen. Die Systempflege des Images kann ich auch über eine VM regeln. Ob ich da das Image drüber bügel oder die VM rüber kopiere ist egal. Doppelt muss ich es so oder so vorhalten, nur der Hypervisor verbraucht geringfügig mehr Ressourcen und bereitet im Sonderfall auch Probleme mit der Peripherie/Hardware oder er wächst etwas an um den Umgang damit zu unterstützen.

Beides sinnvoll und ich würde nicht unbedingt von einer davon abraten ohne den Anwendungsfall zu kennen.

[S_O]

Tut mir Leid das ich erst jetzt antworte, aber die Antwort-Benachrichtigung des Forums wurde vom Spamfilter blockiert, habe das jetzt gerade erst gesehen.

Die Nutzer haben physikalischen Zugang zum System (Notebooks), jede Lösung mit Netzwerk oder zusätzlicher Hardware kommt nicht in Frage. Auch Lösungen die den Start oder das Herunterfahren verzögern sind komplett ungeeignet. Hardware-Write-Blocker kenne ich auch noch aus meiner Schulzeit, das war aber mit Windows 98, die Rechner mit Windows 2000/XP hatten da eine Software. Gibt es für aktuelles Windows auch.

Overlayroot schützt ja bereits das Dateisystem, Problem ist nur root kann das umgehen indem er direkt auf das Block-Device zugreift und so z.B. den Bootloader löscht.

Ich denke ich habe dafür aber bereits eine Lösung gefunden: Hier gibt es einen Kernel-Patch, der write-Befehle auf ein read-only Block-Device verhindert: https://github.com/msuhanov/Linux-write-blocker/
Ich habe ihn nun so ergänzt, dass er nicht nur überprüft ob das read-only-flag gesetzt ist, sondern zusätzlich kann in in der boot command-line angegeben werden welche block-devices immer read-only sind, dass kann auch root nicht ändern (außer in dem extremen Fall er lädt ein spezielles Kernel-Modul nach das den Kernel-Code umschreibt).

[BetterWorld]

Dann verstehe ich den Sinn dieser Aktion endgültig nicht mehr.

Wenn du den Schreibzugriff für root so umständlich blockst,
warum den Users dann nicht schlicht keine root-Rechte geben?

Was unterscheidet denn nun die zwei Szenarien?
Wenn sie als root nicht schreiben können, sind doch die root- Rechte sinnlos.
Das als root ausgeführte Kommando schlägt halt fehl.
Wie beim gleichen Schreibversuch als User; dort aber ohne Modulgefrickel.

[florian0285]

@BW Glaskugel: exotisches "mobile" (notebook) desk sharing. Manchem User würde ich auch gerne Schreibrechte entziehen, wenn nicht sogar eine Schreibmaschine hinstellen. Warum das nicht mit einem üblichen Konzept geht wäre nice to know.
Die Schreiboperationen können ja in z. B. ein ramfs, usb stick o. ä. umgeleitet werden. Wie z. B. hier:

https://kofler.info/raspbian-lite-fuer-den-read-only-betrieb/

Denk daran, dass du den Zugriff auf Grub schützt (booten mit Kernel von anderem Datenträger). Und wer will findet Wege z. B. HDD ausbauen.

[S_O]

Also nochmal: Der Nutzer soll alles dürfen (Programme installieren/aktualisieren) aber keine dauerhaften Änderungen (also Änderungen die einen Neustart überleben) am System vornehmen dürfen. Vor dem zweiten schützt overlayroot, aber ich kann doch keinen fast-root Nutzer anlegen, der zwar überall im Dateisystem schreiben darf und auch sonst alles darf, aber nicht den Bootsektor ändern darf.

Ein weiteres Problem (was allerdings in den letzten Jahren deutlich besser geworden ist): Der Grundgedanke bei den Linux-Rechten ist, dass der Nutzer keinen physikalischen Zugriff auf das System hat, wie kann man es sich sonst erklären, dass ein normaler Nutzer im Normalfall ein Rechner nicht herunterfahren darf wenn er doch auch den Stecker ziehen kann? Durch die Desktop-Oberflächen wird das weitgehend behoben, aber auch nicht immer perfekt. Ich erinnere mich an der Uni an Linux-Rechner an die man zwar problemlos USB-Sticks anschließen konnte die auch automatisch gemountet wurden, aber man konnte sie nicht vernünftig entfernen, weil der User keine Rechte zum unmounten hat. Neben gelegentlichen Datenverlusten auf den Sticks gabs dann auch Fehlermeldungen am Rechner die man ohne root auch nicht weg bekam, da merkte das der Reset-Knopf am Rechner nicht für Windows-Nutzer gedacht ist.
Solche Probleme treten nicht auf wenn der User root-Rechte hat.

[florian0285]

Naja würde ich zu deinem letzten Satz behaupten, dass das nicht auftritt, wenn das System (vom Admin) richtig eingerichtet wurde und du die richtige Distribution verwendet hättest. Ich hab diese Probleme zumindest nie gehabt. Entweder konnte ich am Anfang nur mit root mounten und da ich grundsätzlich ein Upgrade auf die nächste Version erstmal abwarte bis Kinderkrankheiten beseitigt sind, hatte ich diesen Effekt auch nicht als der USB-Stick dann einzug in die DE's gefunden hat.
Es hat auch immerhin seinen Sinn, dass ein User ein Mehrbenutzersystem nicht herunterfahren darf, wenn noch andere daran arbeiten.
Linux für die Allgemeinheit auf den Desktop zu bringen ist immerhin auch erst mit der Zeit gekommen und wie ich schon am Anfang geschrieben habe hatte ich dieses Problem auch nie bei meinen privaten Systemen. Wenn du jedoch in der Uni einen Server am laufen hattest ist das wohl klar, dass da ein User keinen shutdown oder reboot ausführen darf.

Wenn du mit dem kernel-modul die Lösung gefunden hast ist das gut. Wir drei wollten aber den Zweck des ganzen wissen um dir möglicherweise eine "bessere" Möglichkeit empfehlen zu können. Ein System so zu konfigurien, wie du es vor hast, macht im Normalfall keinen Sinn. Mir fallen ein zwei Ausnahmefälle ein, die man aber mit deinem normalen Berechtigungskonzept auch lösen könnte.

Also wenn du dir selbst eventuell eine komplette Neukonfiguration deines Netzes / deiner Geräte in ein paar Wochen oder Monaten ersparen möchtest, weil du später auf Probleme stößt, solltest du uns deinen Anwendungsfall beschreiben. Wenn nicht hoffe ich, dass dein Plan aufgeht und wünsche dir viel Spass :)