Weitere ähnliche Fragen mit mehr Antworten, die es zu beachten gilt:
HINWEIS: Einige der dort gegebenen Antworten verweisen auf bestimmte Lösungen, die hier noch nicht erwähnt wurden.
Tatsächlich gibt es einige Jailing-Tools mit unterschiedlicher Implementierung, aber viele von ihnen sind entweder nicht sicher (wie fakeroot, LD_PRELOAD-basiert) oder nicht vollständig (wie fakeroot-ng, ptrace-basiert) oder erfordern root ( chrootoder plashwerden bei fakechroot erwähnt) Warnschild ).
Dies sind nur Beispiele; Ich dachte daran, sie alle nebeneinander aufzulisten, mit Angabe dieser beiden Funktionen ("Kann man vertrauen?", "Muss Root eingerichtet werden?"), Möglicherweise bei Virtualisierungsimplementierungen auf Betriebssystemebene .
Im Allgemeinen decken die Antworten dort den gesamten beschriebenen Bereich von Möglichkeiten und noch mehr ab:
virtuelle Maschinen / Betriebssystem
Kernel-Erweiterung (wie SELinux)
- (hier in Kommentaren erwähnt),
Chroot
Chroot-basierte Hilfsprogramme (die jedoch als root festgelegt werden müssen, da chrootroot erforderlich ist oder möglicherweise chrootin einem isolierten Namespace ausgeführt werden kann - siehe unten):
[um ein bisschen mehr über sie zu erzählen!]
Bekannte chroot-basierte Isolationstools:
- hasher mit
hsh-runund hsh-shellbefehlen. ( Hasher wurde für die sichere und wiederholbare Erstellung von Software entwickelt.)
- schroot in einer anderen antwort erwähnt
- ...
ptrace
Eine andere vertrauenswürdige Isolationslösung (neben einer seccomp-basierten ) wäre das vollständige Abfangen von Systemanrufen ptrace, wie in der Manpage erklärt für fakeroot-ng:
Im Gegensatz zu früheren Implementierungen verwendet fakeroot-ng eine Technologie, die dem verfolgten Prozess keine Wahl lässt, ob er die "Dienste" von fakeroot-ng verwendet oder nicht. Statisches Kompilieren eines Programms, direktes Aufrufen des Kernels und Bearbeiten des eigenen Adressraums sind alles Techniken, die trivial verwendet werden können, um die LD_PRELOAD-basierte Steuerung eines Prozesses zu umgehen, und die nicht für das Fakeroot-ng gelten. Theoretisch ist es möglich, Fälschungen so zu formen, dass eine vollständige Kontrolle über den verfolgten Prozess besteht.
Während es theoretisch möglich ist, ist es nicht getan worden. Fakeroot-ng geht von bestimmten "gut verhaltenen" Annahmen über den verfolgten Prozess aus, und ein Prozess, der diese Annahmen verletzt, kann in der Lage sein, zumindest einige der "falschen" Umgebungen zu umgehen, die fakeroot-ng ihm auferlegt hat. ng. Sie werden daher dringend davor gewarnt, fakeroot-ng als Sicherheitstool zu verwenden. Fehlerberichte, die besagen, dass ein Prozess absichtlich (im Gegensatz zu versehentlich) der Kontrolle von fake-root-ng entkommen kann, werden entweder als "kein Fehler" geschlossen oder als niedrig priorisiert markiert.
Es ist möglich, dass diese Politik in Zukunft überdacht wird. Vorläufig wurden Sie jedoch gewarnt.
Wie Sie jedoch lesen können, fakeroot-ngist es selbst nicht für diesen Zweck konzipiert.
(Übrigens, ich frage mich, warum sie sich dafür entschieden haben, den seccompauf Chrom basierenden Ansatz anstelle eines auf Chrom basierenden Ansatzes zu verwenden ptrace...)
Von den oben nicht erwähnten Tools habe ich Geordi für mich selbst notiert , weil mir gefallen hat, dass das Steuerungsprogramm in Haskell geschrieben ist.
Bekannte ptrace-basierte Isolationstools:
seccomp
Ein bekannter Weg, um eine Isolation zu erreichen, ist der in Google Chromium verwendete, separate Sandbox-Ansatz . Bei diesem Ansatz wird jedoch vorausgesetzt, dass Sie einen Helfer schreiben, der einige (die zulässigen) der "abgefangenen" Dateizugriffe und andere Systemaufrufe verarbeitet. und bemühen Sie sich natürlich auch, die Systemaufrufe "abzufangen" und sie an den Helfer weiterzuleiten (möglicherweise würde dies sogar das Ersetzen der abgefangenen Systemaufrufe im Code des gesteuerten Prozesses bedeuten; es klingt also nicht Um ganz einfach zu sein: Wenn Sie interessiert sind, lesen Sie lieber die Details als nur meine Antwort.
Weitere Informationen (aus Wikipedia):
(Der letzte Punkt scheint interessant zu sein, wenn man eine allgemeine seccompLösung außerhalb von Chrom sucht . Es gibt auch einen Blog-Beitrag, den der Autor von "seccomp-nurse" lesen sollte : SECCOMP als Sandboxing-Lösung? )
Die Illustration dieses Ansatzes aus dem Projekt "seccomp-nurse" :
Ein "flexibler" Weg in die Zukunft von Linux?
Früher erschienen 2009 auch Vorschläge, den Linux-Kernel zu patchen , damit der seccompModus flexibler wird - damit "viele der Akrobatik, die wir derzeit brauchen, vermieden werden können". ("Akrobatik" bezieht sich auf die Komplikationen beim Schreiben eines Helfers, der viele möglicherweise unschuldige Systemaufrufe im Namen des inhaftierten Prozesses ausführen und die möglicherweise unschuldigen Systemaufrufe im inhaftierten Prozess ersetzen muss.) In einem LWN-Artikel wurde zu diesem Punkt Folgendes geschrieben:
Ein Vorschlag, der herauskam, war, einen neuen "Modus" zu seccomp hinzuzufügen. Die API wurde mit der Idee entworfen, dass unterschiedliche Anwendungen unterschiedliche Sicherheitsanforderungen haben könnten. Es enthält einen "Modus" -Wert, der die Einschränkungen angibt, die eingeführt werden sollen. Es wurde immer nur der Originalmodus implementiert, andere können jedoch hinzugefügt werden. Wenn Sie einen neuen Modus erstellen, in dem der initiierende Prozess angeben kann, welche Systemaufrufe zulässig sind, wird die Funktion für Situationen wie die Chrome-Sandbox nützlicher.
Adam Langley (auch von Google) hat einen Patch gepostet, der genau das tut. Die neue "Modus 2" -Implementierung akzeptiert eine Bitmaske, die beschreibt, auf welche Systemaufrufe zugegriffen werden kann. Wenn eines davon prctl () ist, kann der Sandbox-Code seine eigenen Systemaufrufe weiter einschränken (aber den Zugriff auf Systemaufrufe, die abgelehnt wurden, nicht wiederherstellen). Alles in allem sieht es nach einer vernünftigen Lösung aus, die Sandbox-Entwicklern das Leben erleichtern könnte.
Allerdings wird dieser Code möglicherweise nie zusammengeführt, da die Diskussion inzwischen zu anderen Möglichkeiten übergegangen ist.
Diese "flexible Lösung" würde die Möglichkeiten von Linux der Bereitstellung der gewünschten Funktion im Betriebssystem näher bringen, ohne dass komplizierte Hilfsprogramme geschrieben werden müssten.
(Ein Blogeintrag mit im Wesentlichen demselben Inhalt wie diese Antwort: http://geofft.mit.edu/blog/sipb/33 .)
Namespaces ( unshare)
Das Isolieren durch Namespaces ( unshare-basierte Lösungen ) - hier nicht erwähnt -, z. B. das Aufheben der Freigabe von Mountpunkten (in Verbindung mit FUSE?) , Könnte möglicherweise Teil einer funktionierenden Lösung sein, wenn Sie Dateisystemzugriffe auf Ihre nicht vertrauenswürdigen Prozesse beschränken möchten.
Weitere Informationen zu Namespaces, nachdem deren Implementierung abgeschlossen wurde (diese Isolationstechnik ist auch unter dem Namen "Linux Containers" oder "LXC" bekannt , oder ? ..):
„Eines der allgemeinen Ziele von Namensräumen ist die Umsetzung von Containern, ein Werkzeug für die leichte Virtualisierung (wie auch andere Zwecke) zu unterstützen“ .
Es ist sogar möglich, einen neuen Benutzernamensraum zu erstellen, so dass "ein Prozess eine normale nichtprivilegierte Benutzer-ID außerhalb eines Benutzernamensraums haben kann, während gleichzeitig eine Benutzer-ID von 0 innerhalb des Namensraums vorhanden ist. Dies bedeutet, dass der Prozess über vollständige Root-Berechtigungen verfügt für Operationen innerhalb des Benutzernamensraums, jedoch nicht für Operationen außerhalb des Namensraums ".
Für echte Arbeitsbefehle, um dies zu tun, siehe die Antworten auf:
und spezielle User-Space-Programmierung / Kompilierung
Nun, natürlich können die gewünschten "Gefängnis" -Garantien durch Programmierung im Benutzerbereich implementiert werden ( ohne zusätzliche Unterstützung für diese Funktion durch das Betriebssystem ; möglicherweise wurde diese Funktion deshalb bei der Entwicklung von Betriebssystemen überhaupt nicht berücksichtigt ); mit mehr oder weniger Komplikationen.
Das erwähnte ptrace- oder seccomp-basierte - Sandboxing kann als eine Variante der Implementierung der Garantien angesehen werden, indem ein Sandbox-Helfer geschrieben wird, der Ihre anderen Prozesse steuert, die als "Blackboxes", willkürliche Unix-Programme, behandelt werden.
Ein anderer Ansatz könnte darin bestehen, Programmiertechniken zu verwenden, die sich um die Effekte kümmern, die nicht zugelassen werden müssen. (Dann müssen Sie es sein, die die Programme schreiben; sie sind keine Black Boxes mehr.) Um eines zu erwähnen: Verwenden Sie eine reine Programmiersprache (die Sie zwingen würde, ohne Nebenwirkungen zu programmieren) wie Haskell , um einfach alle Effekte der zu erzielen Programm explizit, so dass der Programmierer leicht sicherstellen kann, dass es keine unzulässigen Effekte gibt.
Ich denke, es gibt Sandbox-Möglichkeiten für diejenigen, die in einer anderen Sprache programmieren, zB Java.
Auf einige Seiten mit Informationen zu diesem Thema wurde auch in den Antworten hingewiesen: