Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Google-Update "brickt" Macs ohne SIP

Google-Update "brickt" Macs ohne SIP

Peter Eckel25.09.1911:12
Aus aktuellem Anlaß möchte ich kurz auf folgenden Artikel bei Heise aufmerksam machen:

Kurz zusammengefaßt:

* Google benutzt einen eigenen Update-Mechanismus für Chrome, der sich tief im System verankert und root-Rechte benötigt.
* Die letzte Version dieses Update-Mechanismus ("Keystone") hat einen Bug, der einen wichtigen Symlink im macOS löscht (warum auch immer).
* Auf Macs mit SIP kann er das nicht, aber auf Geräten, bei denen SIP disabled wurde, resultiert das in einem Mac, der nicht mehr bootet.

Daß Google lieber sein eigenes Süppchen kocht als den Standard-Installer zu verwenden, wundert mich eigentlich nicht. Das kann verschiedene Gründe haben, vor allem aber wohl den, daß Chrome mehr oder weniger auf allen Plattformen läuft und Google keine Lust hat, für jede den jeweils eigenen Installationsmechanismus zu nutzen. Dazu kann man stehen, wie man will - ist halt so.

Aber dann fängt es auch schon an. Es entzieht sich meinem Verständnis vollständig, warum der Installer meint, an einem Verzeichnispfad herumwurschteln zu müssen, der wirklich grundlegend für das Betriebssystem ist. Als Applikation hat Chrome da einfach nichts dran zu suchen. Eine mögliche Erklärung ist noch, daß der Pfad eigentlich "/irgendwas/var" heißen sollte, "/irgendwas" in einer Variable stehen sollte und die versehentlich nicht initialisiert wurde. Aber dann stellt sich gleich die nächste Frage:

Testet sowas keiner? Der Installer erzeugt ja offenbar ein Log - wenn der /var-Symlink gelöscht oder überschrieben wurde, steht das da drin. Also dürfte es auch drinstehen, wenn /var zu löschen oder überschreiben versucht wurde, das aber fehlgeschlagen ist. Entweder hat der Autor das nicht gelesen, oder er hat es einfach ignoriert.

Und das ist ein prinzipielles Problem. Ein Installer, der offenbar mit root-Rechten läuft, sollte immer sehr, sehr sorgfältig getestet werden, und Fehlern im Log muß auf den Grund gegangen werden.

Die nächste Frage, die sich mir stellt, ist, warum ein Browser unbedingt mit root-Rechten installiert werden muß - das ist unüblich, um es mal vorsichtig auszudrücken. Browser sind dermaßen sowas von Userland, da wüßte ich wirklich nicht, wozu man dafür tief im System herumwurschteln muß. Das weiß wohl nur Google - und wohl muß einem dabei nicht sein.

Und als letztes mal wieder eines meiner Lieblingsthemen: Dieser Fehler wurde von SIP abgefangen und verhindert. Eigentlich soll SIP ja vor Malware schützen. Über die Effizienz dieses Verfahrens läßt sich trefflich streiten - meines Erachtens stellt SIP zwar keinen absoluten Schutz vor Malware dar (den gibt es auch nicht), aber eine weitere Barriere, die nicht viel Komfort kostet und einige Angriffsszenarien blockiert.

Offenbar schützt es auch vor schlampig programmierten, schlecht getesteten und unnötig Rechte-gierigen Installationsroutinen. Ob man die jetzt auch schon als Malware bezeichnen will, insbesondere wenn sie von einem erbitterten Konkurrenten kommen, ist Geschmackssache.
„Ceterum censeo librum facierum esse delendum.“
+4

Kommentare

maculi
maculi25.09.1911:17
Nichts gegen Google-bashing, da bin ich gern mit dabei (sie liefern einem ja auch genügend Gründe). Aber muss es wirklich sein, das zum dritten Mal zu erwähnen? Siehe hier und hier .
0
Peter Eckel25.09.1911:34
maculi
Nichts gegen Google-bashing, da bin ich gern mit dabei (sie liefern einem ja auch genügend Gründe). Aber muss es wirklich sein, das zum dritten Mal zu erwähnen?
Anscheinend schon - ich hatte die Updates zu den bestehenden Artikeln, in denen auf die tatsächliche Ursache verwiesen wird, jedenfalls nicht gelesen, sonst hätte ich mir die Arbeit gespart, das nochmal auszuführen ...
„Ceterum censeo librum facierum esse delendum.“
+4

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.