Ich benutze schon seit Jahr und Tag OpenSUSE; aktuell die Version 12.2. Gestern klickte ich durch das Verwaltungstool YAST und stiess dabei auf den Punkt „Sicherheits-Center und Systemhärtung“. Dort kann man einige Einstellungen des Rechners anpassen, um die eigene Sicherheit zu erhöhen. Unter Anderem gibt es einen „Sicherheitsüberblick“; dort kann man schnell sehen, wo noch Anpassungen vorgenommen werden müssen. Besonders fiel mir da der Punkt „Sichere Dateiberechtigungen verwenden“ ins Auge; dort wurde mir Optimierungsbedarf angezeigt. Klickt man dort auf „Konfigurieren“, kann man u.a. beim Punkt „Dateiberechtigungen“ zwischen „Easy (Einfach)“, „Sicher“ und „Paranoid“ wählen. Bei mir war dort „Einfach“ eingestellt.
Ich dachte mir so: machen wir das Ganze doch mal sicherer. Da dort keine weitere Erklärung stand, entschied ich mich erst mal für „Sicher“. Das System wirkte im Hintergrund irgendwelche unsichtbare Magie und nach ein paar Sekunden konnte ich weiterarbeiten. Ich konnte aber keinen Unterschied erkennen und da der heutzutage kurzen Aufmerksamkeitsspanne wandte ich mich anderen Dingen zu.
Das etwas anders war, merkte ich beim nächsten Start von Chromium (dem Browser von Google). Über das in der Menüleiste angeheftete Symbol liess er sich nicht mehr starten und der Start aus einem Terminal heraus brachte eine Fehlermeldung. Da ich kurz vorher auch eine größere Update-Aktion gestartet hatte, vermutete ich den Fehler bei einer neuen Bibliothek. Die Fehlermeldung war:
Sie verwenden eine nicht unterstützte Befehlszeilenmarkierung: –no-sandbox. Dadurch werden Stablilität und Sicherheit beeinträchtigt.
Das klang schon mal nicht gut, da die Sandbox beim Browser (AFAIK) ja nicht ganz unwichtig ist. Ein bisschen Googeln erbrachte, dass der Start über ein Skript erfolgt, dass bei OpenSUSE in der 64-Bit Version unter /usr/lib64/chromium/ liegt: chromium-generic. Innerhalb dieses Skriptes wird dann auch entschieden, ob der Schalter –no-sandbox benutzt wird oder nicht. Am Anfang dieses Skriptes wird die Variable CHROME_SANDBOX auf den Wert /usr/lib/chrome_sandbox gesetzt. Über die Abfrage
! -u $CHROME_SANDBOX
wird dann (so vermute ich; ich bin kein BASH-Spezialist) getestet, ob für chrome_sandbox das setuid-Bit gesetzt ist. Je nach Ergebnis wird dann Chromium mit oder ohne den Parameter –no-sandbox aufgerufen.
Im Internet fand ich dann auch eine Anleitung, wie man das System anpassen kann; aber ich entschied mich erst mal für die einfachere Variante (man will ja nicht noch mehr kaputt machen): Dateiberechtigungen wieder auf „Einfach“ setzen.
Damit war der Fehler dann weg und ruft man in Chromium in der Adressleiste chrome://sandbox/ auf, kann man erkennen, dass die Sandbox wieder funktioniert (bis auf die beiden Punkte mit „Seccomp“; aber dass scheint ein anderes Thema zu sein): der Sandbox-Status meldet „sie haben ausreichend trainiert“.
Bleibt abschliessend noch die Frage, was da im Hintergrund passiert ist. Dazu schauen wir uns die Datei /usr/lib/chromium_sandbox an. Steht „Dateiberechtigungen“ auf „Einfach“, liefert „ls -l /usr/lib/chromium_sandbox“
-rwsr-xr-x 1 root root 16472 10. Sep 11:40 chrome_sandbox
Stellt man aber auf „Sicher“ um, liefert die Abfrage
-rwxr-xr-x 1 root root 16472 10. Sep 11:40 chrome_sandbox
Die Änderung entfernt also das setuid-Bit, womit die Abfrage im Skript dazu führt dass Chromium ohne Sandbox startet.
Und wieder was gelernt…
PS: Sollte ich irgendwas falsch interpretiert haben, würde ich mich über eine entsprechende Information sehr freuen.
]]>