Un programma basato su Chromium si interrompe: «The SUID sandbox helper binary was found, but is not configured correctly»

Discord e altri programmi basati su Electron o Chromium possono fermarsi subito all’avvio con questo messaggio:

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 colloca le pagine di cui esegue il rendering all’interno di una sandbox e supporta due modi per crearne una: uno user namespace (spazio dei nomi utente) oppure, se uno user namespace viene negato, il programma ausiliario setuid chrome-sandbox incluso nel programma. Quando il meccanismo di protezione è attivo, a ogni programma che non figura nel suo elenco viene rifiutato il namespace, e Chromium passa al programma ausiliario. Se il programma ausiliario è stato installato senza il bit setuid, Chromium termina anziché proseguire senza sandbox.

Se un programma sia interessato o meno dipende quindi dal suo programma ausiliario. Arch installa il programma ausiliario con setuid per chromium, per ogni pacchetto electron e per signal-desktop, e brave-bin dell’AUR fa lo stesso, per cui questi programmi si avviano come prima. Sono interessati i programmi che portano con sé un proprio Chromium con un programma ausiliario normale, cosa frequente tra i pacchetti -bin dell’AUR, e ogni programma che viene eseguito dalla vostra directory home. Discord è uno di questi: il pacchetto discord del repository di Arch installa solo un programma di avvio, che scarica Discord in ~/.config/discord e lo avvia da lì.

Per verificare che a rifiutarlo sia stato proprio il meccanismo di protezione, interrogatelo. sudo ditana-userns-guard --status elenca i programmi che ha rifiutato, a partire dal più recente, ciascuno con l’utente che lo ha eseguito e la frequenza; una riga come refused 3x uid 1000 Discord, 12 s ago indica il colpevole. La versione 1.00 del meccanismo di protezione si limita a contare: con questa versione eseguitelo prima e dopo aver avviato il programma, e se denied è aumentato, è stato il meccanismo di protezione.

Per un programma nella vostra directory home, usate invece il suo Flatpak:

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

Flatpak crea la propria sandbox con bubblewrap, che figura nell’elenco, e la sandbox di Discord viene poi eseguita al suo interno. In questo caso non fate ciò che chiede il messaggio. Un file setuid root nella vostra directory home conferisce i privilegi di root a un binario scaricato dal meccanismo di aggiornamento del programma stesso e non verificato da nessuno, e l’aggiornamento successivo ne mette uno nuovo accanto.

Un programma basato su Chromium installato da un pacchetto

La maggior parte dei programmi basati su Chromium o Electron che provengono da un pacchetto si avviano normalmente, poiché il loro pacchetto installa il programma ausiliario della sandbox con setuid root, come fanno i pacchetti chromium ed electron di Arch. Il messaggio compare solo nei casi in cui un pacchetto installa il programma ausiliario senza quel bit, cosa rara che riguarda soprattutto i pacchetti AUR -bin che portano con sé un proprio Electron. Tutti gli altri pacchetti non sono interessati: non hanno un programma ausiliario di questo tipo. Il rimedio consiste nel dare il bit al programma ausiliario. In tal caso Chromium non ha bisogno di alcuno user namespace, motivo per cui questa soluzione è migliore dell’inserimento del programma nell’elenco del meccanismo di protezione. Il comando seguente elenca tutti i programmi ausiliari del sistema privi del bit:

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

Impostare il bit una sola volta non basta, perché l’aggiornamento successivo del pacchetto riscrive il file com’era. Un hook di pacman lo reimposta dopo ogni aggiornamento. Per ogni percorso stampato dal comando, impostate helper su quel percorso ed eseguite:

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"

A differenza di un programma ausiliario nella vostra directory home, questo fa parte di un pacchetto che pacman ha installato e verificato, e un programma ausiliario setuid è esattamente il modo in cui Arch distribuisce Chromium stesso.

Un programma ausiliario privo del bit è un difetto di pacchettizzazione. Il file esiste unicamente per essere setuid root e senza di esso non può fare nulla, e il programma del pacchetto stesso lo conferma nel messaggio riportato sopra. Né si tratta di una particolarità di Ditana: lo stesso kernel linux-hardened di Arch disattiva per impostazione predefinita gli user namespace non privilegiati, e l’Arch Wiki afferma che le applicazioni basate su Chromium hanno allora bisogno del bit setuid su chrome-sandbox. Segnalate il difetto, in modo che il prossimo aggiornamento lo corregga per tutti e l’hook non sia più necessario. pacman -Si <package> mostra il repository di provenienza; un pacchetto elencato da pacman -Qm proviene invece dall’AUR:

• Repository di Arch: una segnalazione su https://gitlab.archlinux.org/archlinux/packaging/packages/<package>/-/issues.
• AUR: un commento su https://aur.archlinux.org/packages/<package>.
• Repository di Ditana: una segnalazione su ditana-build. Ditana compila questi pacchetti a partire da ricette AUR e provvede a inoltrare la segnalazione lì.

È utile indicare la soluzione: installare il programma ausiliario con i permessi 4755, come fanno i pacchetti chromium ed electron di Arch.