Login
Newsletter
Werbung

Thema: Chrome 78 erschienen

7 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von kamome umidori am Mi, 23. Oktober 2019 um 12:40 #

> Ferner kann das Schreiben in bestimmte Verzeichnisse untersagt werden, was unter Linux durch die Dateizugriffsrechte aber unnötig ist.

Wenn ich gezielt Chrom(e|ium) nur Zugriff auf „Downloads“ geben mag, wäre das mit Dateizugriffsrechten aber umständlich, oder (der Browser läuft doch als mein eigener Benutzer)?

  • 0
    Von klopskind am Mi, 23. Oktober 2019 um 15:40 #

    Hm, ich kann Ihre Zitierung des Artikels auch nicht ganz nachvollziehen.

    Und ja, normalerweise läuft der Browser unter dem selben Nutzer wie die gesamte Sitzung. Die großen Browser verwenden unter Linux seccomp-Filter, um bestimmte Teile des Codes oder gesamte Prozesse (Rendering) zu isolieren.

    Jedenfalls denke ich, dass an dieser Stelle mit Dateizugriffsrechte unter Linux keine Kniffe à la separater Benutzer für Browser-Sitzungen oder Firejail mit entsprechendem seccomp-Filter gemeint sind. Das wäre meines Verständnisses nach relativ unpraktikabel.

    Ist etwa gemeint, dass man vor dem Start des Browsers bzw. der WebApp die Schreibrechte des eigenen Benutzers (Besitzer) für diejenigen Dateien entzieht, für die man das Schreiben der WebApp untersagen möchte, und hinterher wieder gewährt?
    Und müsste man das nicht manuell pro Nutzung einer WebApp oder mindestens pro Browserstart durchführen? Das wäre in der Tat etwas umständlich.

    Unter den im Artikel angeführten Quellverweisen konnte ich auf die Schnelle auch nichts Hilfreiches finden.
    Entspricht das Zitat einer Übersetzung aus jenen Quellen?

    @Redaktion: Könnte bitte jemand näher erklären, was genau mit diesem Satz gemeint ist/war? Danke

    0
    Von verchromt am Mi, 23. Oktober 2019 um 16:34 #

    In z.B. /usr/bin kann er halt nicht schreiben.

    • 0
      Von klopskind am Mi, 23. Oktober 2019 um 21:13 #

      Das ist korrekt. War im Artikel mit jenem Satz wirklich das gemeint? Mich deucht nicht.

      Es war unter Linux doch schon zuvor der Fall. Der Browserprozess, ja jeder Prozess, eines Nutzers kann nicht schreiben, wo das Betriebssystem dem Nutzer keine Schreibrechte erteilt (DAC). Webseiten hatten bisher nur relativ eingeschränkte Möglichkeiten (falls vorhanden): Cookies, Caches, Flash, Java-Applets, ActiveX(?) (Downloads/Uploads sind ja explizit nutzerinitiiert via Klicks oder Auswahldialog und werden seit eh und je vom Browser-Prozess umgesetzt; die Webseite hat keine weiteren Zugriffsmöglichkeiten)

      Aber hier im Artikel geht es ja darum, Zugriffe per Browser-API zu verwalten und zu regulieren, sodass WebApps prinzipiell Dateizugriffsrechte anfragen und erhalten können (lesend bzw. schreibend), aber eben nur, falls der Nutzer diesem im Falle des Falles explizit via einer leicht erkennbaren Abfrage zustimmt, um die Zugriffsmöglichkeiten jeder WebApp auf einem Minimum zu reduzieren.
      Bestehende Nutzerrechte des Betriebssystems können ohnehin nicht umgangen werden, selbst wenn der Nutzer und dessen Browser-Sitzungsprozess es wollten, unter der Annahme keine entsprechende Sicherheitslücke, d.h. privilege escalation, im System existiert.
      Es geht also darum, den Nutzer vor bösartigen WebApps zu schützen, indem einer WebApp nur diejenigen Dateien des Nutzers preisgegeben oder zur Verfügung gestellt werden (möglicherweise nur temporär), für die es eine explizite Zustimmung des Nutzers gab.

      Also was genau hat das mit der/dem im Artikel erwähnten neuen API/Feature zu tun? Was ändert sich in diesem Zusammenhang?

      Ist etwa gemeint, dass die Browser-API die Klienteneinstellungen des Nutzers dahingehend berücksichtigt, gewissen oder allen WebApps Zugriffe (lesend/schreibend) auf bestimmte Dateien, auf die er Zugriff hat, generell zu verweigern bzw. die Gewähr einzuschränken? Falls ja, warum wäre das unter Linux unnötig? Wie lösen die Dateizugriffsrechte dieses Problem bzw. setzen das Feature um?
      Die klassische Zugriffsrechteverwaltung unter Linux (DAC) schafft das meiner Ansicht nach nicht - jedenfalls nicht ohne ein zweites (ggf. virtuelles) Nutzerkonto.

      • 0
        Von C64 Fan am Mi, 23. Oktober 2019 um 22:45 #

        Bisher konnte man per Javascript über Windows.localStorage Daten local ablegen. Das ist aber kein Zugriff auf das Dateisystem; wo der Browser die Daten ablegt und wie er sie verwaltet, darauf hat der Webentwickler keinen Einfluß (und kann es auch nicht abfragen/ändern )

        Über die neue Api besteht dann von Javascript aus ein echter Zugriff auf das Dateisystem, das ist natürlich extrem gefährlich, weshalb man den Zugriff dann reglementieren kann.
        Ob die meisten USer vertehen, was sie dann da freigeben ist ein anderes Problem.

        • 0
          Von klopskind am Do, 24. Oktober 2019 um 09:30 #

          Danke für die Erklärungen. Ja, so hatte ich das auch aufgefasst/vermutet.

          Aber wie passt das mit dem Zitat im Eingangskommentar zusammen? Wieso machen unter Linux die Zugriffsrechte ein Untersagen von Schreibrechten auf der Ebene dieser Browser-API für WebApps unnötig? Will man denn, dass dem Anwender nur die Wahl bleibt, einer WebApp entweder alle oder gar keine Schreibrechte seines Benutzers des Browser-Prozesses erbt/erhält, frei nach dem Motto "ganz oder gar nicht"? Ist die Idee dieser Browser-API nicht, dass über explizite Abfragen die Schreibrechte der WebApp auf eine Teilmenge des Benutzers des Browser-Prozesses minimiert werden, sozusagen eine Whitelist über den bestehenden Schreibrechten des Nutzers?

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung