daily.out
2010-04-05
Google Chrome: Sandbox-Mechanismus von OS X rockt
Spätestens seit der Google Chrome Browser am Markt ist, hat man öfter etwas von dem Begriff "Sandbox" gehört. Tatsächlich benutzt Google Chrome auf jedem Betriebssystem einen anderen Sandbox-Mechanismus. Und zwar jeweils einen, den das betreffende System mehr oder weniger zur Verfügung stellt.
Das Interessante daran ist Googles Beurteilung der Sandbox-Fähigkeiten der verschiedenen Betriebssysteme:
Es ist eine ziemlich komplizierte Angelegenheit, um auf Windows einen Prozeß (laufendes Programm) auf eine für uns brauchbare Art in eine Sandbox zu sperren. Der relevante Quellcode dazu besteht aus über 100 Dateien.
Für unsere Google Chrome-Portierung auf Linux-basierte Systeme und auf OS X war Sandboxing eine völlig andere Geschichte:
Für Linux-basierte Systeme gibt es einige verschiedene Sandbox-Mechanismen. Unterschiedliche Linux-Distributionen werden mit unterschiedlichen (oder gar keinen) Sandbox-APIs ausgeliefert. Und einen Mechanismus zu finden, der garantiert auf den Endbenutzer-Maschinen auch funktioniert, ist eine Herausforderung.
Zum Glück sind auf OS X die APIs, um einen Prozeß zu sandboxen, leicht zu benutzen und unkompliziert.
Sie führen auch aus, daß die Google Chrome Sandbox kein neuer Mechanismus ist, sondern auf den Möglichkeiten des jeweiligen Betriebssystems basiert.
Bei Windows geben sie zu bedenken, daß die Sandbox bei systemeigenen Unzulänglichkeiten nicht wirken kann: So können Dateien auf FAT-Dateisystemen nicht geschützt werden. Außerdem können Ressourcen, die (beispielsweise in der Registry) fehlkonfiguriert wurden, nicht von der Sandbox geschützt werden.
Auf OS X verwenden sie mehrere Sandkästen, die den gleichen eingebauten Mechanismus nutzen, den ich auch immer verwende.
Sie benutzen jedoch einen kleinen Trick, um sich die Arbeit zu erleichtern: Wenn ein Prozeß schon bestimmte Ressourcen benutzt, dann darf er das auch noch, wenn er seine Sandbox aktiviert, die ihm Zugriff auf diese Ressource verbieten würde. Sie starten also erstmal den Prozeß, damit er sich alle Ressourcen ziehen kann, die er benötigt, dann aktivieren sie die relativ einfach (das ist gut) gestrickten Sandboxen, die ihm alles andere verbieten. Die Sandbox-Definitionen in "renderer.sb", "utility.sb" und "worker.sb" kann man sich auch in der Chrome.app selbst anschauen, wenn man sich den Paketinhalt (per Control-Klick) des Programms ansieht.
Um noch einmal auf den Vergleich mit Windows zurückzukommen: Auf Windows kann ein Sandkasten nicht dafür garantieren, daß seine Einschränkungen aufrecht erhalten werden (siehe oben). Zudem ist eine Sandbox auf Windows auch um Welten komplizierter (Faktor 100) aufzubauen als auf OS X. Das Schlimmste hier ist jedoch, daß die Sandbox auf Windows durch Fehler an anderen Stellen ausgehebelt werden kann.
Auf OS X ist die Sandbox leicht zu erstellen und einfach zu benutzen. Sie ist auch nicht anfällig für obskure Fehlkonfigurationen im System, die sie löchrig machen könnten.
Der Google Chrome Browser verwendet noch eine Besonderheit: Normalerweise nutzen Programme Threads, um Nebenläufigkeit zu realisieren. Google Chrome startet jedoch für jedes Fenster einen eigenen Prozeß, jeweils "Google Chrome Helper" genannt unter OS X, was dazu führt, daß die Seiten in den jeweiligen Fenstern sich nicht gegenseitig beeinflussen können, da die Prozeßtrennung des Betriebssystems genutzt ist. Threads sind nicht so voneinander getrennt, weil ein Programm normalerweise seinen eigenen Threads vertrauen kann. Browser sind jedoch ein Sonderfall, weil in jedem Fenster potentiell fremder Code ausgeführt werden kann durch manipulierte Seiten. Und dann ist es nützlich, wenn die eine nicht auf die andere Seite zugreifen kann.