bwrap ddsec
1.0.0
Profil de sable sans privilèges pour bubblewrap
De nombreux outils temporels d'exécution des conteneurs, tels que SystemD-Nspawn, DockerEtc., Concentrez-vous sur la fourniture d'infrastructures pour les administrateurs système et les outils d'orchestration (par exemple, Kubernettes) pour exécuter des conteneurs.
Ces outils ne conviennent pas pour les donner aux utilisateurs sans privilèges, car il est trivial de convertir un tel accès en un shell racine avec des privilèges complets dans l'hôte.
Il existe un système d'isolement au niveau du noyau Linux appelé espaces de nom d'utilisateur "utilisateur" utilisateur "qui essaient de permettre aux utilisateurs sans privilèges d'utiliser les fonctions du conteneur. Bien que des progrès significatifs aient été réalisés, il y a encore des préoccupations à cet égard et n'est pas disponible pour les utilisateurs sans privilèges dans plusieurs distributions de production telles que Centos / Red Hat Enterprise Linux 7, Debian Jessie, etc.
Voir, par exemple, CVE-2016-3135, qui est une vulnérabilité des racines locale introduite par les utilisateurs. Cette publication de mars 2016 a plus de discussions.
Bubblewrap pourrait être considéré comme une implémentation entière d'un sous-ensemble d'espaces de noms d'utilisateurs. L'accent mis sur le sous-ensemble - spécifiquement pertinent pour le CVE précédent, Bubblewrap ne permet pas de contrôler les iptables.
Le code Bubblewrap d'origine existait avant les espaces des noms d'utilisateurs: hérite du code d'assistance XDG -App qui, à son tour, est perturbé par Linux-User-Chroot.
Les responsables de cet outil croient que, même lorsqu'il est utilisé en combinaison avec le logiciel typique installé dans cette distribution, il ne permet pas l'escalade des privilèges. Cependant, il peut augmenter la capacité d'un utilisateur qui s'est connecté pour effectuer des attaques de déni de service.
En particulier, Bubblewrap est utilisé PR_SET_NO_NEW_PRIVS pour désactiver SetUid Binary, qui est la façon traditionnelle de sortir de choses comme des chroots.
Ce programme peut être partagé par tous les outils de conteneurs qui ne sont pas enracinés, tels que:
Flatpak RPM-Ostree sans privilèges BWRAP-OCI Nous aimerions également être disponibles dans les grappes Kubernetes / Onshift. Avoir la capacité que les utilisateurs sans privilèges utilisent les fonctions du conteneur faciliteraient considérablement la réalisation de scénarios de purification interactifs et similaires.
Bubblewrap fonctionne en créant un nouvel espace de noms d'assemblage complètement vide, où la racine est dans un TMPFS qui est invisible pour l'hôte, et sera nettoyée automatiquement lorsque le dernier processus se terminera. Ensuite, vous pouvez utiliser les options de ligne de commande pour créer le système de fichiers racine et l'environnement de processus et la commande à exécuter dans l'espace de nom.
Il y a une séquence de commandes de démonstration plus grande dans le code source, mais ici, il existe une petite version qui exécute un nouveau shell réutilisant le fichier / USR.
BWRAP --RO-BIND / USR / USR-SYMLINK USR / LIB64 / LIB64 --proc / Proc --Dev / Dev-Share-Pid Bash Il s'agit d'un exemple incomplet, mais utile à des fins illustratives. Plus souvent, au lieu de créer un conteneur à l'aide de l'arborescence du système de fichiers hôte, vous souhaitez vous inscrire à un chroot. Là, au lieu de créer le lien symbolique Lib64 -> USR / LIB64, TMPFS l'a peut-être déjà créé dans la destination rootfs.
L'objectif de Bubblewrap est d'exécuter une application dans un boîtier de sable, où il a un accès restreint aux parties du système d'exploitation ou des données utilisateur, telles que le répertoire de démarrage.
Bubblewrap crée toujours un nouvel espace de noms d'assemblage, et l'utilisateur peut spécifier exactement quelles parties du système de fichiers doivent être visibles dans le bac à sable. Tous ces répertoires spécifiés seront montés par forme prédéterminée et ne peuvent être faits que la lecture.
De plus, vous pouvez utiliser ces fonctions de noyau:
Espaces de nom d'utilisateur (clone_newuser): Cela cache tout sauf l'UID et le bac à sable actuels. Il peut également modifier la valeur UID / GID dans le bac à sable.
IPC Noms Spaces (CLONE_NEWIPC): Le Box Sand obtiendra sa propre copie de toutes les différentes formes de CPI, telles que la mémoire partagée SYSV et les feux de circulation.
PID Noms Spaces (clone_newpid): Sandbox ne verra aucun processus à l'extérieur du bac à sable. De plus, Bubblewrap exécutera un trivial PID1 dans son conteneur pour gérer les exigences de récolte des enfants dans le boîtier de sable. Cela évite ce qui est maintenant connu sous le nom de problème Docker Pid 1.
Espaces dehttp: //linux.die.net/man/2/clone Noms de réseau (clone_newnet): Sandbox ne verra pas le réseau. Au lieu de cela, vous aurez votre propre espace de nom de réseau avec seulement un périphérique de boucle inversée.
UTS Noms Space (clone_newuts): Le boîtier de sable aura son propre nom d'hôte.
Filtres SecComp: les filtres SecComp qui limitent les appels au système qui peuvent être effectués dans la zone de test peut passer. Pour plus d'informations, voir SecComp.
Firejail est similaire à Flatpak avant que Bubblewrap ne soit divisé en le sentiment qu'il combine un outil SETUID avec de nombreuses fonctions de sable de sable de bureau spécifiques. Par exemple, Firejail connaît Pulseaudio, tandis que Bubblewrap no.
Les auteurs de Bubblewrap croient qu'il est beaucoup plus facile d'auditer un petit programme setuid et de maintenir des caractéristiques telles que le filtrage de Pulaudio comme un processus sans privilèges, comme c'est le cas maintenant dans Flatpak.
De plus, @CGWalters pense que essayer d'inclure des itinéraires de fichiers dans la liste des blancs est une mauvaise idée étant donné les innombrables façons dont les utilisateurs doivent manipuler des itinéraires et d'innombrables façons dont les administrateurs système peuvent configurer un système. L'approche Bubblewrap est de conserver uniquement des capacités Linux spécifiques telles que CAP_SYS_ADMIN, mais accédez toujours au système de fichiers tels que l'invocation UID. Cela ferme complètement les attaques de Tocttou et autres.
Sandstorm.io nécessite des espaces pour les noms d'utilisateurs sans privilèges pour configurer son bac à sable, bien qu'il puisse également s'adapter facilement pour fonctionner en mode setuid. @CGWalters estime que son code est assez bon, mais il pourrait toujours être logique de l'unifier dans Bubblewrap. Cependant, @kentonv (de Sandstorm) estime que bien que cela soit logique en principe, le coût du changement dépasse les avantages pratiques pour l'instant. Cette décision pourrait être réévaluée à l'avenir, mais aujourd'hui elle n'est pas activement appliquée.
Runc travaille actuellement sur la prise en charge des conteneurs sans racine, sans avoir besoin de tout autre privilège lors de l'installation de RUNC (en utilisant des espaces de noms d'utilisateur sans privilèges au lieu de SetUid), la création et l'administration de conteneurs. Cependant, le mode standard d'utilisation de Runc est similaire à SystemD NSPAWN dans lequel il est conçu pour être invoqué par Root.
Les auteurs de Bubblewrap croient que Runc et Systemd-Nspawn ne sont pas conçus pour devenir setuid et sont loin d'admettre un tel moyen. Cependant, avec des conteneurs sans racine, RUNC peut se conformer à certains cas d'utilisation admis par Bubblewrap (avec l'avantage supplémentaire d'être un temps d'exécution OCI complet et standardisé).
Binctr n'est qu'une enveloppe pour Runc, donc il hérite de toutes ses compensations de conception.
