1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Kernel: Defekte Dateisysteme bringen…

Da müsste man in der Tat ziemlich lange entwickeln

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema

Neues Thema Ansicht wechseln


  1. Da müsste man in der Tat ziemlich lange entwickeln

    Autor: Lebenszeitvermeider 20.08.19 - 21:19

    Man könnte beispielsweise mehrstufige Endlosketten mit Blöcken in Dateisystemen bauen und den Kernel damit auf eine Endlosreise schicken. Natürlich könnte man das abfangen, aber es wäre aufwändig, zumal es Dutzende von Varianten gäbe, die man abdecken müsste.

    Macht das Sinn? Nicht direkt: Es hält einen davon ab, reale Probleme zu lösen. Wirklich ultimativ fehlerresistenter Code wäre überaus unleserlich und langsam. Jede beliebige Eventualität müsste ausfindig gemacht werden, und danach durch entsprechenden Code unschädlich, und je mehr man nachdenkt, desto mehr "Eventualitäten" tauchen auf.

    Das Problem wird dann von lebenden Treiberentwicklern lieber im Automount ausgemacht, der unbezähmbaren Bequemlichkeit der User und der infinitesimalen Lernresistenz mancher Distributionen: "Das muss so, weil Windows 95 hat das so gemacht," das ist leider im LInux-Desktop-Bereich immer noch State-of-the-Art.

  2. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: tsx-11 20.08.19 - 21:35

    Zustimmung. Es ist in etwa so, als würde man eine HTML Engine in den Kernel tun und erwarten, dass man die sicher bekommt...

    Einen komplexen Parser für untrusted data tut man nicht in den Kernel. Genau das hat man aber, wenn man externe Medien mit einem Kernel-Dateisystem mounted.

    Die Lösung dieses Problems ist, die Filesysteme dafür in eine Sandbox zu tun. Der ext4 Maintainer hatte mal Mini-VMs dafür vorgeschlagen.

  3. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: Port80 20.08.19 - 21:57

    Könnte das nicht auch über User File Systems gehen (bspw. FUSE)? Oder hat man da wieder im Userspace die gleichen Probleme?

  4. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: freebyte 20.08.19 - 22:00

    Lebenszeitvermeider schrieb:
    --------------------------------------------------------------------------------
    > Macht das Sinn? Nicht direkt: Es hält einen davon ab, reale Probleme zu
    > lösen. Wirklich ultimativ fehlerresistenter Code wäre überaus unleserlich
    > und langsam.

    Postels Law: “be conservative in what you do, be liberal in what you accept from others”

    Und wenn man sich die FS-Sourcen so anschaut, da gehen viele Calleés davon aus dass der Caller keinen Müll einwirft.

    > Jede beliebige Eventualität müsste ausfindig gemacht werden,
    > und danach durch entsprechenden Code unschädlich, und je mehr man
    > nachdenkt, desto mehr "Eventualitäten" tauchen auf.

    Naja, dank "modularer Programmierung" sind die Subroutinen recht spezialisiert. Wenn der Datenträger "N" Sektoren hat kann man ja mal prüfen, ob da nicht "N+1" angefordert wird usw.

    > Das Problem wird dann von lebenden Treiberentwicklern lieber im Automount
    > ausgemacht, der unbezähmbaren Bequemlichkeit der User und der
    > infinitesimalen Lernresistenz mancher Distributionen: "Das muss so, weil
    > Windows 95 hat das so gemacht," das ist leider im LInux-Desktop-Bereich
    > immer noch State-of-the-Art.

    Ultimative Lösung: Wechseldatenträger vor dem Mounten mit fschk behandeln, das dauert aber zu lange. "Weiche" Lösung: der Treiber macht bei Wechseldatenträgern mehr Prüfungen. Zugriff etwas langsamer - verhindert aber, dass ein manipuliertes FS die Maschine wegreisst.

    Wer sich "sicher" fühlt, kann das ja abschalten.

    fb

  5. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: tsx-11 20.08.19 - 22:07

    freebyte schrieb:
    --------------------------------------------------------------------------------
    > "Weiche" Lösung: der Treiber macht bei
    > Wechseldatenträgern mehr Prüfungen. Zugriff etwas langsamer - verhindert
    > aber, dass ein manipuliertes FS die Maschine wegreisst.

    Wie willst du das bei bestehenden Formaten, wie ext4, XFS, etc. lösen? Zum Beispiel, wie erkennst du online, dass die Datenblöcke einer Datei nicht auf Metadaten des Dateisystems zeigen?

  6. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: freebyte 20.08.19 - 22:08

    Port80 schrieb:
    --------------------------------------------------------------------------------
    > Könnte das nicht auch über User File Systems gehen (bspw. FUSE)? Oder hat
    > man da wieder im Userspace die gleichen Probleme?

    Im Prinzip könnte man über sowas wie FUSE gehen.

    Nur: ein FS-Treiber im Kernel sieht anders aus als ein FS-Treiber in FUSE. Um jetzt zB. einen ext4 USB-Stick via FUSE et al zu mounten hat man unterschiedlichen Source.

    Ich denke nicht, dass sich das durch paar Switches im Source abhandeln lässt. Abgesehen davon, dass FS Treiber im Userland nicht wirklich schnell sind.

    fb

  7. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: tsx-11 20.08.19 - 22:10

    Ein FUSE Dateisystem wäre schon mal ein großer Fortschritt. Wenn man das noch in einer Sandbox laufen lässt, wäre es ziemlich sicher.

  8. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: tsx-11 20.08.19 - 22:19

    Man nimmt die Linux Kernel Dateisysteme und kompiliert diese als FUSE. Nennt sich fusefs-lkl. Machen die FreeBSDler so.

  9. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: Schattenwerk 20.08.19 - 22:19

    Du hast Ahnung davon (wenn ja, in welcher Form) oder was qualifiziert dich zu dieser Einschätzung, dass es sicherer wäre?

    Damit es sicher ist, muss zum einem die Sandbox und das FS sicher sein. Das sind schon einmal zwei potenzielle Fehlerquellen anstatt einem direkten FS im Kernel. Und pauschal zu behaupten, dass die Sandbox und das FS sicher sind, wäre genau so dumm, wie die Behauptung, dass ein Block-Device mit einem "nativen FS" im Kernel sicher sein.

  10. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: tsx-11 20.08.19 - 22:25

    Ich habe geschrieben, ziemlich sicher. Nicht sicher.

    Wenn das FS nicht sicher ist, was ist schlimmer. Dies im Kernel zu haben oder in Userspace in einer Sandbox?

  11. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: Hello_World 22.08.19 - 03:41

    tsx-11 schrieb:
    --------------------------------------------------------------------------------
    > Wie willst du das bei bestehenden Formaten, wie ext4, XFS, etc. lösen? Zum
    > Beispiel, wie erkennst du online, dass die Datenblöcke einer Datei nicht
    > auf Metadaten des Dateisystems zeigen?

    Warum sollte das nötig sein? Es geht doch hier nur darum, dass das FS keine Sicherheitslücken haben soll, wenn es mit einem kaputten oder manipulieren FS konfrontiert wird. Es soll nicht abstürzen, nicht in eine Endlosschleife geraten, keine Datenstrukturen im Hauptspeicher korrumpieren etc., aber IMO ist es kein Problem, wenn z. B. ein ohnehin manipuliertes FS noch weiter zerstört wird. Das sollte eigentlich ohne größere Verrenkungen möglich sein.

  12. Re: Da müsste man in der Tat ziemlich lange entwickeln

    Autor: schily 22.08.19 - 13:07

    Also, als Frank Hoffman von Sun Microsystems und ich das 2005 und 2006 für das ISO-9660 Filesystem gemacht haben (nachdem ein Hinweis der FreeBSD Leute kam), war die Vorgehensweise folgende:

    Man erzeugt ein FIlesystem mit vielen 0 Byte großen Dateien, damit ist praktisch alles Meta-Daten.

    Dann schreibt man ein Programm, das zufällig ausgewählte Bytes mit einem zufällig anderen Wert überschreibt.

    Nun mountet man das Filesystem und startet danach ein ls -lR auf dem Filesystem.

    Wenn das Betriebssystem dabei abstürzt, dann hebt man das Filesystemimage auf und untersucht später den Kernel-Coredump mit dem Kerneldebugger.

    Dieses Verfahren haben wir damals auch den Linux Leuten gemeldet mit dem Hinweis darauf, das die Linux Implementierung alle bei Solaris gefundenen Bugs auch hat. Bei Linux war man allerdings nicht interessiert.

    Kleiner Hinweis: wir haben so lange weiter nach Bugs gesucht, bis diese Suchmethode einen Monat lang ohne neuen Bug durchlief. Nachdem ich Joliet Support in den Solaris ISO-9660 Code nachgerüstet hatte, haben wir dennoch weitere Bugs entdeckt, weil durch die Joliet Erweiterungen mehr Directory Einträge auf den ersten Blick zulässig sind und damit vorher als fehlerhaft erkannte Einträge auf den Rest des Codes durchgegeben wurden und dieser Code noch unentdeckte Fehler hatte.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Allianz Deutschland AG, München Unterföhring
  2. Rundfunk Berlin-Brandenburg (rbb), Berlin
  3. Mainova AG, Frankfurt am Main
  4. HABA Group B.V. & Co. KG, Bad Rodach bei Coburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 68,23€
  2. jetzt registrieren
  3. (u. a. Dead by Daylight für 5,49€, Cities Skylines Deluxe Edition für 5,29€, Resident Evil 3...
  4. 148,27€ (mit Rabattcode "POWERSUMMER20" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


  1. Xiaomi: Elektromoped Ninebot C30 kostet nur 470 Euro
    Xiaomi
    Elektromoped Ninebot C30 kostet nur 470 Euro

    Ninebot hat mit dem C30 ein elektrisches Moped vorgestellt, das preiswert ist und eine Alternative zum ÖPNV und dem Fahrrad darstellt.

  2. Terrorismus: Gamer unter Terrorverdacht
    Terrorismus
    Gamer unter Terrorverdacht

    Plattformen wie Steam oder Xbox Live seien nahezu unüberwacht, findet der Antiterrorkoordinator der EU. Und will das ändern. Seine Argumente sind schwierig.

  3. AMD Ryzen: Threadripper Pro unterstützen 2 TByte RAM
    AMD Ryzen
    Threadripper Pro unterstützen 2 TByte RAM

    Die Threadripper-Pro-CPUs mit bis zu 64 Kernen und acht Speicherkanälen stecken in Lenovos Thinkstation P620.


  1. 07:46

  2. 07:24

  3. 18:30

  4. 18:01

  5. 17:30

  6. 17:00

  7. 16:53

  8. 16:35