Bubblewrap

Molti strumenti di runtime per container come systemd-nspawn, docker, ecc. si concentrano sul fornire infrastruttura per amministratori di sistema e strumenti di orchestrazione (es. Kubernetes) per eseguire container.

Questi strumenti non sono adatti a essere affidati a utenti non privilegiati, perché è banale trasformare tale accesso in una shell root completamente privilegiata sull'host.

Namespace utente

Nel kernel Linux esiste una funzionalità chiamata namespace utente che consente agli utenti non privilegiati di usare le funzionalità dei container. Bubblewrap usa questi namespace per costruire la sandbox, permettendo a qualsiasi utente di usare lo strumento.

Storicamente, bubblewrap supportava anche una modalità setuid per i sistemi in cui i namespace utente non privilegiati non erano supportati. Tuttavia, questa è stata rimossa.

Il codice originale di bubblewrap esisteva prima dei namespace utente - eredita codice da xdg-app helper che a sua volta deriva lontanamente da linux-user-chroot.

Sicurezza del sistema

I manutentori di questo strumento ritengono che esso non permetta l'elevazione dei privilegi, anche quando usato in combinazione con il software tipicamente installato su tale distribuzione. Può tuttavia aumentare la capacità di un utente autenticato di effettuare attacchi di denial of service.

In particolare, bubblewrap usa PR_SET_NO_NEW_PRIVS per disattivare i binari setuid, che è il modo tradizionale per uscire da ambienti come le chroot.

Sicurezza della sandbox

bubblewrap è uno strumento per costruire ambienti sandbox. bubblewrap non è una sandbox completa e pronta all'uso con una specifica politica di sicurezza.

Alcuni casi d'uso di bubblewrap richiedono un confine di sicurezza tra la sandbox e il sistema reale; altri casi d'uso richiedono la capacità di modificare il layout del filesystem per i processi all'interno della sandbox, ma non mirano a essere un confine di sicurezza. Di conseguenza, il livello di protezione tra i processi in sandbox e il sistema host è interamente determinato dagli argomenti passati a bubblewrap.

Qualunque programma costruisca gli argomenti della riga di comando per bubblewrap (spesso un framework più ampio come Flatpak, libgnome-desktop, sandwine o uno script ad-hoc) è responsabile di definire il proprio modello di sicurezza e di scegliere gli opportuni argomenti della riga di comando di bubblewrap per implementare tale modello di sicurezza.

Alcuni aspetti della sicurezza della sandbox che richiedono particolare attenzione sono descritti nella sezione Limitazioni qui sotto.

Utenti

Questo programma può essere condiviso da tutti gli strumenti per container che eseguono operazioni non-root, come:

• Flatpak
• rpm-ostree unprivileged
• bwrap-oci

Vorremmo anche vedere questo strumento disponibile nei cluster Kubernetes/OpenShift. La possibilità per gli utenti non privilegiati di usare le funzionalità dei container renderebbe significativamente più semplice svolgere scenari di debug interattivi e simili.

Installazione

bubblewrap è disponibile nei repository dei pacchetti della maggior parte delle distribuzioni Linux e può essere installato da lì.

Se devi compilare bubblewrap dal sorgente, puoi farlo con meson:

meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir

Utilizzo

bubblewrap funziona creando un nuovo namespace di mount, completamente vuoto, in cui la root si trova su un tmpfs invisibile all'host, e che verrà automaticamente ripulito quando l'ultimo processo termina. Puoi quindi usare le opzioni della riga di comando per costruire il filesystem root, l'ambiente dei processi e il comando da eseguire nel namespace.

Nel codice sorgente c'è uno script demo più ampio, ma ecco una versione ridotta che esegue una nuova shell riutilizzando /usr dell'host.

bwrap \
    --ro-bind /usr /usr \
    --symlink usr/lib64 /lib64 \
    --proc /proc \
    --dev /dev \
    --unshare-pid \
    --new-session \
    bash

Questo è un esempio incompleto, ma utile a scopo illustrativo. Più spesso, invece di creare un container usando l'albero del filesystem dell'host, si punta a una chroot. In quel caso, piuttosto che creare il symlink lib64 -> usr/lib64 nel tmpfs, potresti averlo già creato nel rootfs di destinazione.

Sandboxing

L'obiettivo di bubblewrap è eseguire un'applicazione in una sandbox, dove ha accesso limitato a parti del sistema operativo o ai dati dell'utente, come la directory home.

bubblewrap crea sempre un nuovo namespace di mount, e l'utente può specificare esattamente quali parti del filesystem devono essere visibili nella sandbox. Qualsiasi directory specificata viene montata nodev per impostazione predefinita e può essere resa di sola lettura.

Inoltre puoi usare queste funzionalità del kernel:

Namespace utente (CLONE_NEWUSER): nasconde alla sandbox tutto tranne l'uid e il gid correnti. Puoi anche cambiare il valore di uid/gid all'interno della sandbox.

Namespace IPC (CLONE_NEWIPC): la sandbox otterrà una propria copia di tutte le diverse forme di IPC, come la memoria condivisa SysV e i semafori.

Namespace PID (CLONE_NEWPID): la sandbox non vedrà alcun processo al di fuori di essa. Inoltre, bubblewrap eseguirà un banale pid1 all'interno del tuo container per gestire i requisiti di raccolta dei processi figli nella sandbox. Questo evita quello che è noto come problema del pid 1 di Docker.

Namespace di rete (CLONE_NEWNET): la sandbox non vedrà la rete. Avrà invece un proprio namespace di rete con solo un dispositivo di loopback.

Namespace UTS (CLONE_NEWUTS): la sandbox avrà un proprio hostname.

Filtri seccomp: puoi passare filtri seccomp che limitano quali syscall possono essere eseguite nella sandbox. Per maggiori informazioni, vedi Seccomp.

Limitazioni

Come indicato nella sezione Sicurezza della sandbox qui sopra, il livello di protezione tra i processi in sandbox e il sistema host è interamente determinato dagli argomenti passati a bubblewrap. Alcuni aspetti che richiedono particolare attenzione sono indicati qui.

• Se non filtri i comandi TIOCSTI usando filtri seccomp, l'argomento --new-session è necessario per proteggersi dall'esecuzione di comandi fuori dalla sandbox (vedi CVE-2017-5226).

• Tutto ciò che viene montato nella sandbox può potenzialmente essere usato per elevare i privilegi. Ad esempio, se fai un bind di un socket D-Bus nella sandbox, può essere usato per eseguire comandi tramite systemd. Puoi usare xdg-dbus-proxy per filtrare la comunicazione D-Bus.