Ein Programm auf Chromium-Basis bricht ab: «The SUID sandbox helper binary was found, but is not configured correctly»

Discord und andere Programme auf Basis von Electron oder Chromium können gleich beim Start mit dieser Meldung abbrechen:

FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /home/user/.config/discord/app-1.0.157/chrome-sandbox is owned by root and has mode 4755.

Chromium sperrt die Seiten, die es darstellt, in eine Sandbox und unterstützt zwei Wege, eine solche aufzubauen: einen Benutzer-Namensraum (user namespace) oder, falls ein Benutzer-Namensraum verweigert wird, den setuid-Helfer chrome-sandbox, der dem Programm beiliegt. Wenn der Wächter aktiv ist, wird jedem Programm, das nicht auf seiner Liste steht, der Namensraum verweigert, und Chromium wechselt zum Helfer. Wurde der Helfer ohne das setuid-Bit installiert, bricht Chromium ab, statt ohne Sandbox weiterzumachen.

Ob ein Programm betroffen ist, hängt deshalb von seinem Helfer ab. Arch installiert den Helfer mit setuid für chromium, für jedes Paket von electron und für signal-desktop, und das Paket brave-bin aus dem AUR tut dasselbe; diese Programme starten also wie bisher. Betroffen sind Programme, die ein eigenes Chromium mit einem gewöhnlichen Helfer mitbringen, was bei den Paketen des AUR mit der Endung -bin häufig ist, sowie jedes Programm, das aus Ihrem Benutzerverzeichnis läuft. Discord gehört dazu: Das Paket discord aus der Paketquelle von Arch installiert nur ein Startprogramm, das Discord nach ~/.config/discord herunterlädt und von dort startet.

Um sicherzugehen, dass es der Wächter war, der den Namensraum verweigert hat, fragen Sie den Wächter. sudo ditana-userns-guard --status listet die Programme auf, denen er einen Namensraum verweigert hat, die jüngsten zuerst, jeweils mit dem Benutzerkonto, unter dem sie liefen, und der Häufigkeit; eine Zeile wie refused 3x uid 1000 Discord, 12 s ago nennt den Verursacher. Version 1.00 des Wächters zählt nur: Führen Sie den Befehl dort vor und nach dem Start des Programms aus; ist denied gestiegen, war es der Wächter.

Verwenden Sie für ein Programm in Ihrem Benutzerverzeichnis stattdessen sein Flatpak:

sudo flatpak install flathub com.discordapp.Discord
sudo pacman -Rns discord

Flatpak baut seine Sandbox mit bubblewrap auf, das auf der Liste steht, und die eigene Sandbox von Discord läuft dann darin. Tun Sie in diesem Fall nicht, was die Meldung verlangt. Eine Datei mit setuid root in Ihrem Benutzerverzeichnis verleiht Root-Rechte an eine Binärdatei, die das Programm selbst über seine Aktualisierungsfunktion heruntergeladen hat und die niemand überprüft hat, und die nächste Aktualisierung legt eine neue daneben.

Ein Programm auf Chromium-Basis aus einem Paket

Die meisten Programme auf Basis von Chromium oder Electron, die aus einem Paket stammen, starten normal, weil ihr Paket den Sandbox-Helfer mit setuid root installiert, wie es die Pakete chromium und electron von Arch tun. Die Meldung erscheint nur, wenn ein Paket den Helfer ohne dieses Bit installiert; das ist selten und betrifft vor allem AUR-Pakete mit der Endung -bin, die ein eigenes Electron mitbringen. Alle anderen Pakete sind nicht betroffen: Bei ihnen gibt es keinen solchen Helfer. Die Abhilfe besteht darin, dem Helfer das Bit zu geben. Chromium braucht dann überhaupt keinen Benutzer-Namensraum; deshalb ist das besser, als das Programm auf die Liste des Wächters zu setzen. Folgender Befehl listet jeden Helfer auf dem System auf, dem das Bit fehlt:

find /usr /opt -type f \( -name chrome-sandbox -o -name chrome_sandbox \) \( ! -user root -o ! -perm -4001 \)

Das Bit einmal zu setzen, genügt nicht, weil die nächste Aktualisierung des Pakets die Datei wieder so schreibt, wie sie war. Ein pacman-Hook setzt es nach jeder Aktualisierung erneut. Setzen Sie für jeden Pfad, den der Befehl ausgegeben hat, helper auf diesen Pfad und führen Sie Folgendes aus:

helper=/opt/example/chrome-sandbox
sudo mkdir -p /etc/pacman.d/hooks
sudo tee "/etc/pacman.d/hooks/$(pacman -Qqo "$helper")-chrome-sandbox.hook" > /dev/null <<HOOK
[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = ${helper#/}

[Action]
Description = Making the Chromium sandbox helper in ${helper%/*} setuid root...
When = PostTransaction
Exec = /usr/bin/chmod 4755 $helper
HOOK
sudo chmod 4755 "$helper"

Anders als ein Helfer in Ihrem Benutzerverzeichnis gehört dieser zu einem Paket, das pacman installiert und überprüft hat, und ein setuid-Helfer ist genau die Art, wie Arch Chromium selbst ausliefert.

Ein Helfer ohne das Bit ist ein Paketierungsfehler. Die Datei existiert einzig, um setuid root zu sein, und kann ohne das Bit nichts tun, und das Programm des Pakets selbst bestätigt dies in der Meldung oben. Eine Besonderheit von Ditana ist das auch nicht: Der Kernel linux-hardened von Arch selbst schaltet unprivilegierte Benutzer-Namensräume standardmässig aus, und das Arch-Wiki hält fest, dass Anwendungen auf Chromium-Basis dann das setuid-Bit auf chrome-sandbox brauchen. Melden Sie den Fehler, damit die nächste Aktualisierung ihn für alle behebt und der Hook nicht mehr nötig ist. pacman -Si <package> zeigt die Paketquelle, aus der das Paket stammt; ein Paket, das pacman -Qm auflistet, stammt stattdessen aus dem AUR:

• Paketquelle von Arch: ein Issue unter https://gitlab.archlinux.org/archlinux/packaging/packages/<package>/-/issues.
• AUR: ein Kommentar unter https://aur.archlinux.org/packages/<package>.
• Ditana-Paketquelle: ein Issue unter ditana-build. Ditana baut diese Pakete aus AUR-Rezepten und leitet die Meldung dorthin weiter.

Es hilft, die Korrektur zu nennen: den Helfer mit dem Modus 4755 zu installieren, wie es die Pakete chromium und electron von Arch tun.