Un programme basé sur Chromium s’interrompt : « The SUID sandbox helper binary was found, but is not configured correctly »

Discord et d’autres programmes basés sur Electron ou Chromium peuvent s’arrêter dès le démarrage avec ce message :

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 place les pages qu’il affiche dans un bac à sable, et il prend en charge deux façons d’en construire un : un espace de noms utilisateur ou, si un espace de noms utilisateur lui est refusé, le programme auxiliaire setuid chrome-sandbox fourni avec le programme. Lorsque le gardien est actif, tout programme qui ne figure pas sur sa liste se voit refuser l’espace de noms, et Chromium se rabat sur l’auxiliaire. Si l’auxiliaire a été installé sans le bit setuid, Chromium s’arrête au lieu de continuer sans bac à sable.

Le fait qu’un programme soit concerné dépend donc de son auxiliaire. Arch installe l’auxiliaire en setuid pour chromium, pour chaque paquet electron et pour signal-desktop, et le brave-bin de l’AUR fait de même ; ces programmes démarrent donc comme avant. Sont concernés les programmes qui embarquent leur propre Chromium avec un auxiliaire ordinaire, ce qui est courant parmi les paquets -bin de l’AUR, ainsi que tout programme qui s’exécute depuis votre répertoire personnel. Discord en fait partie : le paquet discord du dépôt Arch n’installe qu’un lanceur, qui télécharge Discord dans ~/.config/discord et le démarre depuis cet emplacement.

Pour confirmer que le refus vient bien du gardien, interrogez le gardien. sudo ditana-userns-guard --status liste les programmes qu’il a refusés, les plus récents en premier, chacun avec l’utilisateur qui l’a lancé et la fréquence ; une ligne telle que refused 3x uid 1000 Discord, 12 s ago désigne le coupable. La version 1.00 du gardien se contente de compter : dans ce cas, exécutez la commande avant et après avoir lancé le programme, et si denied a augmenté, c’était le gardien.

Pour un programme situé dans votre répertoire personnel, utilisez plutôt son Flatpak :

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

Flatpak construit son bac à sable avec bubblewrap, qui figure sur la liste, et le bac à sable propre à Discord s’exécute alors à l’intérieur. Dans ce cas, ne faites pas ce que demande le message. Un fichier setuid root dans votre répertoire personnel donne les privilèges root à un binaire téléchargé par le propre outil de mise à jour du programme et que personne n’a vérifié, et la mise à jour suivante en place un nouveau à côté.

Un programme basé sur Chromium provenant d’un paquet

La plupart des programmes basés sur Chromium ou Electron qui proviennent d’un paquet démarrent normalement, car leur paquet installe l’auxiliaire du bac à sable en setuid root, comme le font les paquets chromium et electron d’Arch. Le message n’apparaît que lorsqu’un paquet installe l’auxiliaire sans ce bit, ce qui est rare et concerne surtout des paquets AUR -bin qui embarquent leur propre Electron. Aucun autre paquet n’est concerné : aucun n’a d’auxiliaire de ce type. Le remède consiste à donner ce bit à l’auxiliaire. Chromium n’a alors plus besoin d’aucun espace de noms utilisateur, c’est pourquoi cette solution est préférable à l’ajout du programme sur la liste du gardien. La commande suivante liste tous les auxiliaires du système auxquels ce bit manque :

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

Définir le bit une seule fois ne suffit pas, car la mise à jour suivante du paquet rétablit le fichier dans son état d’origine. Un crochet pacman le redéfinit après chaque mise à jour. Pour chaque chemin affiché par la commande, affectez-le à helper et exécutez :

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"

Contrairement à un auxiliaire situé dans votre répertoire personnel, celui-ci fait partie d’un paquet que pacman a installé et vérifié, et c’est précisément avec un auxiliaire setuid qu’Arch fournit Chromium lui-même.

Un auxiliaire dépourvu de ce bit est un défaut d’empaquetage. Le fichier n’existe que pour être setuid root et ne peut rien faire sans cela, et le programme du paquet lui-même le confirme dans le message ci-dessus. Ce n’est pas non plus propre à Ditana : le propre noyau linux-hardened d’Arch désactive par défaut les espaces de noms utilisateur non privilégiés, et le wiki d’Arch indique que les applications basées sur Chromium ont alors besoin du bit setuid sur chrome-sandbox. Signalez-le, afin que la prochaine mise à jour le corrige pour tout le monde et que le crochet ne soit plus nécessaire. pacman -Si <package> indique le dépôt dont il provient ; un paquet que pacman -Qm liste provient en revanche de l’AUR :

• Dépôt Arch : un ticket à l’adresse https://gitlab.archlinux.org/archlinux/packaging/packages/<package>/-/issues.
• AUR : un commentaire à l’adresse https://aur.archlinux.org/packages/<package>.
• Dépôt Ditana : un ticket sur ditana-build. Ditana compile ces paquets à partir de recettes de l’AUR et y transmet le signalement.

Il est utile de mentionner le correctif : installer l’auxiliaire avec le mode 4755, comme le font les paquets chromium et electron d’Arch.