containers/bubblewrapOutil de sandboxing non privilégié de bas niveau utilisé par Flatpak et des projets similaires.
De nombreux outils d'exécution de conteneurs comme systemd-nspawn, docker, etc. se concentrent sur la fourniture d'une infrastructure permettant aux administrateurs système et aux outils d'orchestration (par exemple Kubernetes) d'exécuter des conteneurs.
Ces outils ne conviennent pas à une utilisation par des utilisateurs non privilégiés, car il est trivial de transformer un tel accès en un shell root totalement privilégié sur l'hôte.
Il existe une fonctionnalité du noyau Linux appelée namespaces utilisateur qui permet aux utilisateurs non privilégiés d'utiliser les fonctionnalités de conteneur. Bubblewrap les utilise pour construire le sandbox, permettant ainsi à n'importe quel utilisateur d'utiliser l'outil.
Historiquement, bubblewrap prenait également en charge un mode setuid pour les systèmes où les namespaces utilisateur non privilégiés n'étaient pas pris en charge. Cette fonctionnalité a toutefois été supprimée.
Le code original de bubblewrap existait avant les namespaces utilisateur - il hérite du code de xdg-app helper, qui dérive lui-même de loin de linux-user-chroot.
Les mainteneurs de cet outil estiment qu'il ne permet pas l'élévation de privilèges, même lorsqu'il est utilisé en combinaison avec les logiciels habituellement installés sur cette distribution. Il peut en revanche accroître la capacité d'un utilisateur connecté à mener des attaques par déni de service.
En particulier, bubblewrap utilise PR_SET_NO_NEW_PRIVS pour désactiver les binaires setuid, ce qui est la méthode traditionnelle pour sortir de choses comme les chroots.
bubblewrap est un outil permettant de construire des environnements sandbox. bubblewrap n'est pas un sandbox complet et prêt à l'emploi doté d'une politique de sécurité spécifique.
Certains cas d'utilisation de bubblewrap exigent une frontière de sécurité entre le sandbox et le système réel ; d'autres cas d'utilisation veulent pouvoir modifier l'agencement du système de fichiers pour les processus à l'intérieur du sandbox, sans chercher à constituer une frontière de sécurité. Par conséquent, le niveau de protection entre les processus sandboxés et le système hôte est entièrement déterminé par les arguments passés à bubblewrap.
Le programme qui construit les arguments de ligne de commande pour bubblewrap (souvent un framework plus vaste comme Flatpak, libgnome-desktop, sandwine ou un script ad hoc) est responsable de la définition de son propre modèle de sécurité et du choix des arguments de ligne de commande bubblewrap appropriés pour mettre en œuvre ce modèle de sécurité.
Certains aspects de la sécurité du sandbox qui nécessitent une attention particulière sont décrits dans la section Limitations ci-dessous.
Ce programme peut être partagé par tous les outils de conteneurisation qui fonctionnent sans privilèges root, tels que :
Nous aimerions également que cet outil soit disponible dans les clusters Kubernetes/OpenShift. Pouvoir offrir aux utilisateurs non privilégiés l'accès aux fonctionnalités de conteneur rendrait les scénarios de débogage interactif et autres nettement plus faciles.
bubblewrap est disponible dans les dépôts de paquets de la plupart des distributions Linux et peut être installé à partir de ceux-ci.
Si vous devez compiler bubblewrap à partir des sources, vous pouvez le faire avec meson :
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap fonctionne en créant un nouveau namespace de montage complètement vide, dont la racine se trouve sur un tmpfs invisible depuis l'hôte et qui sera automatiquement nettoyé lorsque le dernier processus se terminera. Vous pouvez ensuite utiliser les options de ligne de commande pour construire le système de fichiers racine, l'environnement du processus et la commande à exécuter dans le namespace.
Il existe un script de démonstration plus complet dans le code source, mais voici une version allégée qui lance un nouveau shell en réutilisant le /usr de l'hôte.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
Cet exemple est incomplet, mais utile à titre d'illustration. Le plus souvent, plutôt que de créer un conteneur à partir de l'arborescence du système de fichiers de l'hôte, vous souhaiterez cibler un chroot. Dans ce cas, plutôt que de créer le lien symbolique lib64 -> usr/lib64 dans le tmpfs, vous l'avez peut-être déjà créé dans le rootfs cible.
L'objectif de bubblewrap est d'exécuter une application dans un sandbox, où elle a un accès restreint à certaines parties du système d'exploitation ou des données utilisateur, comme le dossier personnel.
bubblewrap crée toujours un nouveau namespace de montage, et l'utilisateur peut spécifier exactement quelles parties du système de fichiers doivent être visibles dans le sandbox. Tous les répertoires que vous spécifiez sont montés avec l'option nodev par défaut et peuvent être rendus en lecture seule.
Vous pouvez en outre utiliser ces fonctionnalités du noyau :
Namespaces utilisateur (CLONE_NEWUSER) : cela masque au sandbox tout sauf l'uid et le gid actuels. Vous pouvez également modifier la valeur de l'uid/gid dans le sandbox.
Namespaces IPC (CLONE_NEWIPC) : le sandbox obtient sa propre copie de toutes les formes d'IPC, comme la mémoire partagée SysV et les sémaphores.
Namespaces PID (CLONE_NEWPID) : le sandbox ne verra aucun processus en dehors du sandbox. De plus, bubblewrap exécutera un pid1 minimal à l'intérieur de votre conteneur pour répondre aux exigences de la récolte des processus enfants dans le sandbox. Cela évite ce que l'on appelle désormais le problème du pid 1 de Docker.
Namespaces réseau (CLONE_NEWNET) : le sandbox ne verra pas le réseau. Il disposera à la place de son propre namespace réseau avec seulement un périphérique de bouclage.
Namespace UTS (CLONE_NEWUTS) : le sandbox aura son propre nom d'hôte.
Filtres seccomp : vous pouvez passer des filtres seccomp qui limitent les appels système pouvant être effectués dans le sandbox. Pour plus d'informations, voir Seccomp.
Comme indiqué dans la section Sécurité du sandbox ci-dessus, le niveau de protection entre les processus sandboxés et le système hôte est entièrement déterminé par les arguments passés à bubblewrap. Certains aspects nécessitant une attention particulière sont notés ici.
TIOCSTI à l'aide de filtres seccomp, l'argument --new-session est nécessaire pour se protéger contre l'exécution de commandes hors du sandbox (voir CVE-2017-5226).