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.
Si vous ne filtrez pas les commandes 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).
Tout ce qui est monté dans le sandbox peut potentiellement être utilisé pour élever les privilèges. Par exemple, si vous liez un socket D-Bus dans le sandbox, il peut être utilisé pour exécuter des commandes via systemd. Vous pouvez utiliser xdg-dbus-proxy pour filtrer les communications D-Bus.
Certaines applications déploient leurs propres mécanismes de sandboxing, et ceux-ci peuvent être restreints par les contraintes imposées par le sandboxing de bubblewrap. Par exemple, certains navigateurs web configurent leurs processus enfants via seccomp pour qu'ils n'aient pas accès au système de fichiers. Si vous limitez les appels système et n'autorisez pas l'appel système seccomp, un navigateur ne peut pas appliquer ces restrictions. De même, si ces règles sont compilées dans un fichier qui n'est pas disponible dans le sandbox, le navigateur ne peut pas charger ces règles depuis ce fichier et ne peut pas appliquer ces restrictions.
Firejail est similaire à Flatpak avant la scission de bubblewrap, en ce sens qu'il combine un outil setuid avec de nombreuses fonctionnalités de sandboxing spécifiques au bureau. Par exemple, Firejail connaît Pulseaudio, contrairement à bubblewrap.
Les auteurs de bubblewrap pensent qu'il est beaucoup plus facile d'auditer un petit programme setuid et de conserver des fonctionnalités telles que le filtrage Pulseaudio dans un processus non privilégié, comme c'est désormais le cas dans Flatpak.
De plus, @cgwalters pense que tenter de mettre en liste blanche des chemins de fichiers est une mauvaise idée compte tenu de la myriade de façons dont les utilisateurs peuvent manipuler les chemins et de la myriade de façons dont les administrateurs système peuvent configurer un système. L'approche de bubblewrap consiste à ne conserver que quelques capacités Linux spécifiques, telles que CAP_SYS_ADMIN, mais à toujours accéder au système de fichiers avec l'uid de l'appelant. Cela élimine entièrement les attaques TOCTTOU et autres.
Sandstorm.io nécessite des namespaces utilisateur non privilégiés pour mettre en place son sandbox, bien qu'il puisse facilement être adapté pour fonctionner également en mode setuid. @cgwalters estime que leur code est plutôt bon, mais qu'il pourrait tout de même être judicieux de s'unifier autour de bubblewrap. Cependant, @kentonv (de Sandstorm) estime que même si cela a du sens en principe, le coût de la migration l'emporte pour l'instant sur les avantages pratiques. Cette décision pourrait être réévaluée à l'avenir, mais elle n'est pas activement poursuivie aujourd'hui.
runC travaille actuellement sur la prise en charge des conteneurs rootless, sans avoir besoin de setuid ni d'aucun autre privilège lors de l'installation de runC (en utilisant des namespaces utilisateur non privilégiés plutôt que setuid), de la création et de la gestion des conteneurs. Cependant, le mode d'utilisation standard de runC est similaire à systemd nspawn dans la mesure où il s'agit d'un outil destiné à être invoqué par root.
Les auteurs de bubblewrap pensent que runc et systemd-nspawn ne sont pas conçus pour être rendus setuid et sont loin de prendre en charge un tel mode. Cependant, avec les conteneurs rootless, runC pourra répondre à certains cas d'utilisation pris en charge par bubblewrap (avec l'avantage supplémentaire d'être un runtime OCI standardisé et complet).
binctr n'est qu'un wrapper pour runC, il hérite donc de tous ses compromis de conception.
Le nom bubblewrap a été choisi pour exprimer le fait que cet outil s'exécute en tant que parent de l'application (il l'enveloppe donc en quelque sorte) et crée une couche de protection (le sandbox) autour d'elle.
(Chat Bubblewrap par dancing_stupidity)