neue Version des Tools , das fĂŒr die Organisation von isolierten Umgebungen unter Linux gedacht ist und auf der Anwendungsebene fĂŒr nicht privilegierte Benutzer funktioniert. In der Praxis wird Bubblewrap vom Flatpak-Projekt als Schicht zur Isolierung von Anwendungen verwendet, die aus Paketen gestartet werden. Der Code des Projekts ist in C geschrieben und unter der LGPLv2+-Lizenz.
Zur Isolierung werden die traditionellen Technologien der Container-Virtualisierung fĂŒr Linux verwendet, die auf cgroups, Namespaces, Seccomp und SELinux basieren. Um privilegierte Operationen zur Konfiguration des Containers durchzufĂŒhren, wird Bubblewrap mit Root-Rechten (eine ausfĂŒhrbare Datei mit SUID-Flag) gestartet, gefolgt von einem Privilegienabbau nach Abschluss der Containerinitialisierung.
Die Aktivierung der Benutzer-Namensraum-Identifikatoren (user namespaces), die es ermöglichen, in Containern einen eigenen, separaten Satz von Identifikatoren zu verwenden, ist fĂŒr den Betrieb nicht erforderlich, da sie standardmĂ€Ăig in vielen Distributionen nicht funktioniert (Bubblewrap wird als eingeschrĂ€nkte SUID-Implementierung einer Teilmenge der Möglichkeiten von User-Namespace positioniert â zur Ausschluss aller Benutzer- und Prozessidentifikatoren aus der Umgebung, auĂer dem aktuellen, werden die Modi CLONE_NEWUSER und CLONE_NEWPID verwendet). FĂŒr zusĂ€tzlichen Schutz werden Programme, die unter
Bubblewrap ausgefĂŒhrt werden, im PR_SET_NO_NEW_PRIVS-Modus gestartet, der das Erlangen neuer Privilegien verbietet, beispielsweise wenn das setuid-Flag gesetzt ist.
Die Isolierung auf Dateisystemebene erfolgt durch die standardmĂ€Ăige Schaffung eines neuen Mount-Namensraums, in dem mit tmpfs ein leeres Root-Dateisystem erstellt wird. Notwendige Partitionen eines externen Dateisystems werden bei Bedarf im Modus âmount âbindâ an dieses Dateisystem angehĂ€ngt (zum Beispiel wird bei der AusfĂŒhrung mit der Option âbwrap âro-bind /usr /usrâ das Verzeichnis /usr aus dem Hauptsystem im Nur-Lese-Modus bereitgestellt). Die Netzwerkfunktionen beschrĂ€nken sich auf den Zugang zum Loopback-Interface, wĂ€hrend der Netzwerkstack durch die Flags CLONE_NEWNET und CLONE_NEWUTS isoliert wird.
Ein wesentliches Unterscheidungsmerkmal zu einem Ă€hnlichen Projekt , der ebenfalls ein Startmodell mit setuid verwendet, besteht darin, dass die Bubbleswrap-Schicht zur Erstellung von Containern nur das notwendige Minimum an Funktionen enthĂ€lt, wĂ€hrend alle erweiterten Funktionen, die zum AusfĂŒhren von grafischen Anwendungen, zur Interaktion mit dem Desktop und zur Filterung von Anfragen an Pulseaudio erforderlich sind, auf die Seite von Flatpak verschoben werden und nach dem Entziehen der Berechtigungen ausgefĂŒhrt werden. Firejail hingegen vereint alle zugehörigen Funktionen in einer ausfĂŒhrbaren Datei, was die ĂberprĂŒfung und die Sicherheitswartung erschwert. .
Die neue Version ist bemerkenswert, da sie die UnterstĂŒtzung fĂŒr die Anbindung bestehender Benutzer-Namespaces (user namespaces) und Prozess-Namespaces (pid namespaces) implementiert. Um die Verbindung von Namespaces zu steuern, wurden die Flags ââusernsâ, ââuserns2â und ââpidnsâ hinzugefĂŒgt.
Diese Funktion funktioniert nicht im setuid-Modus und erfordert die Verwendung eines separaten Modus, der ohne Root-Rechte arbeiten kann, jedoch die Aktivierung von
Benutzernamespace in dem System voraussetzt (standardmĂ€Ăig in Debian und RHEL/CentOS deaktiviert) und schlieĂt nicht aus, dass FĂŒr die Begrenzung der "user namespaces" gibt es neue Funktionen. In der neuen Version von Bubblewrap 0.4 wird auch die Möglichkeit hervorgehoben, mit der C-Bibliothek musl anstelle von glibc zu kompilieren, sowie die UnterstĂŒtzung zur Speicherung von Informationen ĂŒber Namespaces in einer JSON-Statistikdatei.
Quelle: opennet.ru
