LXC - Linux Containers - Kennt das wer?

svenr

Registered User
Hallo Freunde der leichten Unterhaltung,

hatten grade ein bissl das Gespräch im Chat bzgl Virtualisierungen und ressaurcenschonenden Möglichkeiten. Dabei kam das Gespräch u.a. auf:
LXC http://linuxcontainers.org

Ich habe davon bisher nie gehört und es noch nicht getestet.
Es ging insbesondere um eine Alternative zu Openvz.

Dachte ich werfe mal die Frage in die Runde, ob das schon wer kennt und damit Erfahrungswerte hat.

Gruß Sven
 
Ja, ich hab unter Arch damit mal ein paar Debian-Container aufgesetzt. Gab AFAIK Probleme, weil das Debian-Template irgendwie kaputt war.
 
Wenn es läuft, ist es eigentlich ganz nett - aber es ist halt eben Containervirtualisierung, die ich persönlich nicht dazu verwenden würde um für fremde Personen vServer bereitzustellen.
Realistisch betrachtet ist das ein init-Prozess in einer chroot-Umgebung... ;)

Für so Dinge wie Separierung von Diensten auf einer physikalischen Maschine ist das aber eigentlich ganz brauchbar, wenn man das Debian-Template manuell geradezieht.
 
Hm ok, ich sehe schon das ist nicht das was ich mir davon versprochen habe.
Danke euch beiden fürs Antworten.

Gruß Sven
 
LXC ist ja streng genommen erstmal garkeine Virtualisierung im engeren Sinne - es kommt sogar ohne die Virtual-Machine-Extensions der CPU aus und läuft damit sogar auf Raspberry oder Intel Atom.

Was Sicherheitsaspekte betrifft:
Das Problem dabei ist, dass da keine richtig tolle Separierung zwischen Gast und Host stattfindet.
Es fängt ja schon bei der Festplatte an, wo du einfach ein Verzeichnis hast, in dem sich das Root-Dateisystem des Gastes befindet und in welches der Gast hinein chrooted wird. Mit ein bisschen Mühe und Hintergrundwissen kann man aus diesem Chroot-Jail ausbrechen und damit dann den Host und andere Gäste kompromittieren.
Da der Kernel des Hostsystems zum größten Teil mit hineingereicht wird sparst du dir etwas RAM, hast aber auch den Nachteil dass ein kleiner Bug im Kernel es den Gästen erlauben könnte mit entsprechenden Kernelaufrufen entweder den Host crashen zu lassen (das wäre der Idealfall) oder sogar eigene Befehle mit höchsten Privilegien auszuführen. So einen Bug hat es in Kernel 2.6.18 mal gegeben, der in den damaligen Xen-Umgebungen teilweise bis zum Host durchschlagen konnte. Einen shared Kernel will man also eigentlich auch nicht haben.

Wenn man LXC nutzt um damit einfach nur Dienste etwas zu separieren, ist das wirklich nicht schlecht. Es erhöht vielleicht nicht zwingend die Sicherheit, aber bei Diensten die sich nur mit hohem Aufwand nebeneinander betreiben lassen oder Spezialkonfigurationen bräuchten (z.B. zwei Postfix-Instanzen mit vollkommen unterschiedlicher Konfiguration nebeneinander), kann man LXC wunderbar dafür einsetzen.
 
Mit ein bisschen Mühe und Hintergrundwissen kann man aus diesem Chroot-Jail ausbrechen und damit dann den Host und andere Gäste kompromittieren
Es ist zu betonen dass LXC und OpenVz _WIE_ Chroot Jails sind aber halt keine chroot sind ( man merkt es u.a. mal daran dass es massiver Kernel-Patches bedarf um alle Features, Beschränkungen und Sicherheitsmerkmale bereit zu stellen) und somit die chroot-ist-unsicher Angaben gar nicht erst gelten.

Generell bedarf es bei OpenVZ, LXC, Linux-vserver immer eines Kernel-Exploits (oder Exploit in den implementierungsspezifischen Patches/Modulen) welcher zudem aus dem Guest erreichbar sein muss damit eine Kompromittierung überhaupt klappen kann.

Es ist wahr dass Isolierung (es ist wie bereits angesprochen keine Virtualisation, Paravirtualisation, Simulation oder Emulation sondern reine Isolation) Nachteile und Risiken (sowohl reel als auch prinzipiell) birgt, aber es gibt keine öffentlich bekannte Methode aus einem solchen Jail aus zu brechen.

Wenn man LXC nutzt um damit einfach nur Dienste etwas zu separieren, ist das wirklich nicht schlecht
Solange der Dienst nicht als root läuft kann er auch aus einer chroot nicht ausbrechen. Somit absolut Overkill eine volle Isolierung darauf zu stecken.

der in den damaligen Xen-Umgebungen teilweise bis zum Host durchschlagen konnte.
Ääähm. Xen ist Paravirtualisierung, nicht Isolierung. Hat also auch gar keinen shared Kernel.

sparst du dir etwas RAM
RAM ist nur ein Punkt. Da gäbe es noch zu betrachten: Overhead, kein bis schlecht mögliches Overcomitten, kein shared Cache (damit fällt dmcache/flashcache weg), höhere CPU-Belastung weil in jedem VM ein komplett eigenes Betriebssystem laufen muss, ...
 
Last edited by a moderator:
Back
Top