Abo
  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

  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. Zum Login

Stellenmarkt
  1. Caritas Wohn- und Werkstätten im Erzbistum Paderborn e. V., Paderborn
  2. WBS GRUPPE, deutschlandweit (Home-Office)
  3. Gemeinde Burgkirchen a.d.Alz, Burgkirchen a.d. Alz
  4. LIDL Stiftung & Co. KG, Neckarsulm

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Garmin Fenix 6 im Test: Laufzeitmonster mit Sonne im Herzen
Garmin Fenix 6 im Test
Laufzeitmonster mit Sonne im Herzen

Bis zu 24 Tage Akkulaufzeit, im Spezialmodus sogar bis zu 120 Tage: Garmin setzt bei seiner Sport- und Smartwatchserie Fenix 6 konsequent auf Akku-Ausdauer. Beim Ausprobieren haben uns neben einem System zur Stromgewinnung auch neue Energiesparoptionen interessiert.
Ein Test von Peter Steinlechner

  1. Fenix 6 Garmins Premium-Wearable hat ein Pairing-Problem
  2. Wearable Garmin Fenix 6 bekommt Solarstrom

Party like it's 1999: Die 510 letzten Tage von Sega
Party like it's 1999
Die 510 letzten Tage von Sega

Golem retro_ Am 9.9.1999 kam in den USA mit der Sega Dreamcast die letzte Spielkonsole der 90er Jahre auf den Markt. Es sollte auch die letzte Spielkonsole von Sega werden. Aber das wusste zu diesem Zeitpunkt noch niemand.
Von Martin Wolf


    Recruiting: Wenn das eigene Wachstum zur Herausforderung wird
    Recruiting
    Wenn das eigene Wachstum zur Herausforderung wird

    Gerade im IT-Bereich können Unternehmen sehr schnell wachsen. Dabei können der Fachkräftemangel und das schnelle Onboarding von neuen Mitarbeitern zum Problem werden. Wir haben uns bei kleinen Startups und Großkonzernen umgehört, wie sie in so einer Situation mit den Herausforderungen umgehen.
    Von Robert Meyer

    1. Recruiting Alle Einstellungsprozesse sind fehlerhaft
    2. LoL Was ein E-Sport-Trainer können muss
    3. IT-Arbeit Was fürs Auge

    1. Digitale Signalübertragung: VDV möchte mehr Geld für ETCS-Umrüstungen
      Digitale Signalübertragung
      VDV möchte mehr Geld für ETCS-Umrüstungen

      Das Fahren von Zügen auf Strecken ohne sichtbare Signale wird von der Bundesregierung gefördert. Dem Verband der Verkehrsunternehmen (VDV) reicht das Geld für die ETCS-Ausrüstung aber nicht, er möchte eine Aufstockung, da die Kosten enorm hoch sind.

    2. iOS 13 im Test: Apple macht iOS hübscher
      iOS 13 im Test
      Apple macht iOS hübscher

      Ab dem 19. September 2019 wird die fertige Version von iOS 13 verteilt. Apple hat den Fokus diesmal mehr auf sichtbare Verbesserungen des Nutzererlebnisses gelegt: Wir haben uns den neuen Dark Mode, die verbesserte Kamera-App und weitere Neuerungen angeschaut und interessante Funktionen gefunden.

    3. T-Systems: Niemand konnte erklären, "warum wir so aufgestellt sind"
      T-Systems
      Niemand konnte erklären, "warum wir so aufgestellt sind"

      Die komplizierte Struktur bei T-Systems konnte dem Chef Adel Al-Saleh niemand logisch erklären. Nun wechseln 5.000 T-Systems-Beschäftigte zur Telekom Deutschland.


    1. 12:30

    2. 12:03

    3. 12:02

    4. 11:17

    5. 11:05

    6. 10:50

    7. 10:33

    8. 10:11