containers/bubblewrapStrumento di sandboxing di basso livello senza privilegi usato da Flatpak e progetti simili
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.
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.
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.
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.
Questo programma può essere condiviso da tutti gli strumenti per container che eseguono operazioni non-root, come:
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.
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
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.
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.
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.
Alcune applicazioni implementano i propri meccanismi di sandboxing, che possono essere limitati dai vincoli imposti dal sandboxing di bubblewrap. Ad esempio, alcuni browser web che configurano i propri processi figli tramite seccomp per non avere accesso al filesystem. Se limiti le syscall e non permetti la syscall seccomp, un browser non può applicare queste restrizioni. Allo stesso modo, se queste regole fossero compilate in un file non disponibile nella sandbox, il browser non può caricare queste regole dal file e non può applicare queste restrizioni.
Firejail è simile a Flatpak prima che bubblewrap fosse separato, in quanto combina uno strumento setuid con molte funzionalità di sandboxing specifiche per il desktop. Per esempio, Firejail conosce Pulseaudio, mentre bubblewrap no.
Gli autori di bubblewrap ritengono che sia molto più facile verificare un piccolo programma setuid e mantenere funzionalità come il filtraggio di Pulseaudio come processo non privilegiato, come ora accade in Flatpak.
Inoltre, @cgwalters pensa che cercare di
mettere in whitelist i percorsi dei file
sia una cattiva idea, data la miriade di modi in cui gli utenti possono manipolare
i percorsi, e la miriade di modi in cui gli amministratori di sistema possono configurare un
sistema. L'approccio di bubblewrap è di mantenere solo alcune specifiche
capability Linux come CAP_SYS_ADMIN, ma di accedere sempre al
filesystem come uid che invoca. Questo chiude completamente
gli attacchi TOCTTOU e
simili.
Sandstorm.io richiede namespace utente non privilegiati per impostare la propria sandbox, sebbene potrebbe essere facilmente adattato per operare anche in modalità setuid. @cgwalters ritiene che il loro codice sia abbastanza buono, ma potrebbe comunque avere senso unificare su bubblewrap. Tuttavia, @kentonv (di Sandstorm) ritiene che, sebbene ciò abbia senso in linea di principio, il costo del passaggio superi i benefici pratici per ora. Questa decisione potrebbe essere rivalutata in futuro, ma oggi non è perseguita attivamente.
runC sta attualmente lavorando al
supporto dei container rootless,
senza la necessità di setuid o di altri privilegi durante l'installazione,
la creazione e la gestione dei container di runC (usando namespace utente non privilegiati
invece di setuid). Tuttavia, la modalità standard di
utilizzo di runC è simile a systemd nspawn
in quanto è uno strumento pensato per essere invocato da root.
Gli autori di bubblewrap ritengono che runc e systemd-nspawn non siano progettati per essere resi setuid, e siano lontani dal supportare tale modalità. Tuttavia, con i container rootless, runC sarà in grado di soddisfare alcuni casi d'uso che bubblewrap supporta (con il vantaggio aggiuntivo di essere un runtime OCI standardizzato e completo).
binctr è solo un wrapper per runC, quindi eredita tutti i suoi compromessi di progettazione.
Il nome bubblewrap è stato scelto per comunicare che questo strumento viene eseguito come processo padre dell'applicazione (quindi la avvolge in un certo senso) e crea uno strato protettivo (la sandbox) attorno ad essa.
(Gatto bubblewrap di dancing_stupidity)