bwrap ddsec
1.0.0
Sandboxing -Profil ohne Privilegien für Bubblewrap
Viele Tools für Containerausführungszeiten wie Systemd-Nspawn, Dockeretc.
Diese Tools sind nicht geeignet, um sie ohne Berechtigungen den Benutzern zu geben, da es trivial ist, einen solchen Zugriff in eine Root -Shell mit vollständigen Berechtigungen im Host umzuwandeln.
Auf der Linux -Kernel -Ebene befindet sich ein Isolationssystem mit dem Namen "Benutzernamen" -Nutzernamenräume, in denen Benutzer ohne Berechtigungen die Funktionen des Containers verwenden können. Obwohl erhebliche Fortschritte erzielt wurden, gibt es in dieser Hinsicht immer noch Bedenken und ist für Benutzer ohne Privilegien in mehreren Produktionsverteilungen wie CentOS / Red Hat Enterprise Linux 7, Debian Jessie usw. nicht verfügbar.
Siehe beispielsweise CVE-2016-3135, eine von den Benutzern vorgestellte lokale Anfälligkeit. Die Veröffentlichung in der März 2016 wird mehr diskutiert.
BubbleWrap kann als eine ganze Implementierung einer Teilmenge von Benutzernamenräumen angesehen werden. Schwerpunkt auf der Untergruppe - speziell für das vorherige CVE relevante Bubblewrap erlaubt keine Kontrolle über Iptables.
Der ursprüngliche BubbleWrap-Code wurde vor dem Benutzern von Leerzeichen vorhanden: Erbt den XDG-App-Helfercode, der wiederum durch Linux-User-Chroot gestört wird.
Die Betreuer dieses Tools glauben, dass selbst in Kombination mit der in dieser Verteilung installierten typischen Software keine Berechtigungskalation zulässt. Es kann jedoch die Kapazität eines Benutzers erhöhen, der sich angemeldet hat, um Dienstverweigerungsangriffe durchzuführen.
Insbesondere wird BubbleWrap verwendet.
Dieses Programm kann von allen Container -Tools geteilt werden, die keine Root -Vorgänge wie:
Flatpak RPM-Stree ohne BWRAP-OCI-Privilegien Wir möchten auch, dass dies in den Kubernetes / OnShift-Clustern verfügbar ist. Die Fähigkeit, dass Benutzer ohne Privilegien die Funktionen des Containers verwenden, würde die Realisierung interaktiver und ähnlicher Reinigungsszenarien erheblich erleichtern.
BubbleWrap funktioniert, indem ein neuer, vollständig leerer Montageraum erstellt wird, in dem sich die Wurzel in einem TMPFS befindet, das für den Host unsichtbar ist und beim letzten Ende automatisch gereinigt wird. Anschließend können Sie die Befehlszeilenoptionen verwenden, um das Stammdateisystem und die Prozessumgebung sowie den Befehl zu erstellen, um im Namensraum auszuführen.
Es gibt eine größere Demonstrationsbefehlssequenz im Quellcode, aber hier gibt es eine kleine Version, die eine neue Shell ausführt, die die Datei /USR wiederverwendet.
BWRAP-RO-BIND /USR /USR-Symlink usr /lib64 /lib64-Proc /Proc-Dev /Dev-Share-Pid-Bash Dies ist ein unvollständiges Beispiel, aber nützlich für veranschaulichende Zwecke. Anstatt einen Container mit dem Host -Dateisystembaum zu erstellen, möchten Sie sich häufiger für einen Chroot anmelden. Anstatt den symbolischen Link LIB64 -> USR/LIB64 zu erstellen, haben TMPFs ihn möglicherweise bereits in den Zielwurzeln erstellt.
Das Ziel von BubbleWrap ist es, eine Anwendung in einem Sandkasten auszuführen, in dem ein eingeschränkter Zugriff auf Teile des Betriebssystems oder Benutzerdaten wie das Startverzeichnis eingeschränkt ist.
BubbleWrap erstellt immer einen neuen Platz für Montage -Namen, und der Benutzer kann genau angeben, welche Teile des Dateisystems in der Sandbox sichtbar sein sollen. Jedes dieser angegebenen Verzeichnisse wird durch vorgegebene Form montiert und kann nur gelesen werden.
Darüber hinaus können Sie diese Kernelfunktionen verwenden:
Benutzername Räume (Clone_Newuser): Dies verbirgt alles außer der aktuellen UID und der Sandbox. Es kann auch ändern, was der UID / GID -Wert in der Sandbox sein sollte.
IPC -Namensräume (Clone_Newipc): Die Sandkasten erhält eine eigene Kopie aller verschiedenen Formen von CPI, wie z. B. Shared Memory und Ampeln von SYSV.
PID -Namensräume (Clone_Newpid): Sandbox wird außerhalb der Sandbox keinen Vorgang angezeigt. Darüber hinaus führt BubbleWrap ein PID1 -Trivial in seinem Behälter aus, um die Anforderungen der Ernte von Kindern in der Sandkiste zu erfüllen. Dies vermeidet das heutige Problem mit dem Docker PID 1.
Spaces DEHTTP: //linux.die.net/man/2/Clone -Netzwerknamen (Clone_Newnet): Sandbox wird das Netzwerk nicht angezeigt. Stattdessen haben Sie Ihren eigenen Netzwerknamenraum nur mit einem umgekehrten Schleifengerät.
UTS -Namen Space (Clone_Newuts): Die Sandbox hat einen eigenen Hostnamen.
SECComp -Filter: SECComp -Filter, die die Aufrufe des Systems beschränken, die in der Testzone durchgeführt werden können, können übergeben. Weitere Informationen finden Sie in SecComp.
FireJail ähnelt Flatpak, bevor Bubblewrap in das Gefühl unterteilt wurde, dass es ein SetUid -Tool mit vielen spezifischen Desktop -Sandboxfunktionen kombiniert. Zum Beispiel kennt FireJail Pulseatio, während Bubblewrap -Nr.
Bubblewrap -Autoren glauben, dass es viel einfacher ist, ein kleines SetUID -Programm zu prüfen und Eigenschaften wie das Pulsaudio -Filterung als Prozess ohne Privilegien aufrechtzuerhalten, wie es jetzt in Flatpak der Fall ist.
Darüber hinaus ist @CGWalters der Ansicht, dass der Versuch, Dateirouten in die weiße Liste aufzunehmen, eine schlechte Idee ist, wenn man die unzähligen Arten, wie Benutzer Routen und unzählige Möglichkeiten manipulieren müssen, ein System konfigurieren können. Der BubbleWrap -Ansatz besteht darin, nur einige spezifische Linux -Funktionen wie CAP_SYS_ADMIN beizubehalten, aber immer auf das Dateisystem wie die Aufruf -UID zugreifen. Dies schließt die Tottou -Angriffe und andere vollständig ab.
Sandstorm.io benötigt Leerzeichen für Benutzernamen ohne Berechtigungen, um seine Sandbox zu konfigurieren, obwohl es sich auch leicht an den Betrieb in einem SetUid -Modus anpassen kann. @Cgwalterers glaubt, dass sein Code ziemlich gut ist, aber es könnte immer noch sinnvoll sein, sich in Bubblewrap zu vereinen. @Kentonv (von Sandstorm) ist jedoch der Ansicht, dass dies zwar im Prinzip sinnvoll ist, die Kosten für Veränderungen vorerst die praktischen Vorteile übersteigen. Diese Entscheidung könnte in Zukunft neu bewertet werden, aber heute wird sie nicht aktiv angewendet.
RUNC arbeitet derzeit ohne Root an der Containerunterstützung, ohne dass andere Berechtigungen während der Installation von RunC (Verwendung von Benutzernamenräumen ohne Berechtigungen anstelle von SETUID), die Erstellung und die Verwaltung von Containern verwendet werden müssen. Der Standardmodus der Verwendung von RunC ähnelt jedoch systemd nspawn, in dem er von Root aufgerufen werden soll.
Bubblewrap-Autoren glauben, dass Runc und Systemd-Nspawn nicht so konzipiert sind, dass sie SetUid werden, und weit davon entfernt, einen solchen Weg zuzugeben. Bei Containern ohne Wurzel kann RUNC jedoch bestimmte Anwendungsfälle entsprechen, die von BubbleWrap zugelassen werden (mit dem zusätzlichen Vorteil, dass sie eine vollständige und standardisierte OCI -Ausführungszeit ist).
Binctr ist nur ein Umschlag für Runc, also erbt er alle seine Designausgleich.
