LXC ist die bekannte und vielfach getestete Low-Level-Linux-Container-Laufzeitumgebung. Es befindet sich seit 2008 in der aktiven Entwicklung und hat sich weltweit in kritischen Produktionsumgebungen bewährt. Einige seiner wichtigsten Mitwirkenden sind dieselben Leute, die bei der Implementierung verschiedener bekannter Containerisierungsfunktionen im Linux-Kernel mitgeholfen haben.
Typ | Service | Status |
---|---|---|
CI (Linux) | GitHub | |
CI (Linux) | Jenkins | |
Projektstatus | CII-Best Practices | |
Fuzzing | OSS-Fuzz | |
Fuzzing | CIFuzz |
Der Schwerpunkt von LXC liegt auf Systemcontainern. Das heißt, Container, die eine Umgebung bieten, die der einer VM so nahe wie möglich kommt, aber ohne den Overhead, der mit der Ausführung eines separaten Kernels und der Simulation der gesamten Hardware verbunden ist.
Dies wird durch eine Kombination von Kernel-Sicherheitsfunktionen wie Namespaces, obligatorischer Zugriffskontrolle und Kontrollgruppen erreicht.
Unprivilegierte Container sind Container, die ohne jegliche Privilegien ausgeführt werden. Dies erfordert Unterstützung für Benutzernamensräume im Kernel, auf dem der Container ausgeführt wird. LXC war die erste Laufzeitumgebung, die unprivilegierte Container unterstützte, nachdem Benutzernamensräume in den Hauptkernel integriert wurden.
Im Wesentlichen isolieren Benutzernamensräume bestimmte Sätze von UIDs und GIDs. Dies wird erreicht, indem eine Zuordnung zwischen einem Bereich von UIDs und GIDs auf dem Host und einem anderen (nicht privilegierten) Bereich von UIDs und GIDs im Container erstellt wird. Der Kernel übersetzt diese Zuordnung so, dass innerhalb des Containers alle UIDs und GIDs so angezeigt werden, wie Sie es vom Host erwarten würden, während diese UIDs und GIDs auf dem Host tatsächlich nicht privilegiert sind. Beispielsweise könnte ein Prozess, der im Container mit UID und GID 0 ausgeführt wird, auf dem Host als UID und GID 100000 angezeigt werden. Die Implementierungs- und Arbeitsdetails können der entsprechenden Manpage zum Benutzernamensraum entnommen werden.
Da unprivilegierte Container eine Sicherheitsverbesserung darstellen, unterliegen sie natürlich einigen Einschränkungen, die vom Kernel erzwungen werden. Um einen voll funktionsfähigen unprivilegierten Container bereitzustellen, interagiert LXC mit drei Teilen Setuid-Code:
Alles andere wird als Ihr eigener Benutzer oder als UID ausgeführt, die Ihr Benutzer besitzt.
Im Allgemeinen besteht das Ziel von LXC darin, alle im Kernel verfügbaren Sicherheitsfunktionen zu nutzen. Dies bedeutet, dass das Konfigurationsmanagement von LXC es erfahrenen Benutzern ermöglicht, LXC genau an ihre Bedürfnisse anzupassen.
Eine ausführlichere Einführung in die LXC-Sicherheit finden Sie unter folgendem Link
Grundsätzlich kann LXC ohne eines dieser Tools ausgeführt werden, sofern die richtige Konfiguration angewendet wird. Allerdings ist der Nutzen solcher Behälter meist recht eingeschränkt. Um nur die beiden häufigsten Probleme hervorzuheben:
Netzwerk: Ohne auf einen setuid-Helfer angewiesen zu sein, um geeignete Netzwerkgeräte für einen nicht privilegierten Benutzer einzurichten (siehe LXCs lxc-user-nic
-Binärdatei), besteht die einzige Möglichkeit darin, den Netzwerk-Namespace mit dem Host zu teilen. Obwohl dies grundsätzlich sicher sein sollte, ist die gemeinsame Nutzung des Netzwerknamensraums des Hosts immer noch ein Schritt weniger Isolation und erhöht den Angriffsvektor. Wenn sich Host und Container außerdem denselben Netzwerk-Namespace teilen, lehnt der Kernel außerdem jegliche sysfs-Mounts ab. Dies bedeutet normalerweise, dass die Init-Binärdatei im Container nicht ordnungsgemäß gestartet werden kann.
Benutzernamespaces: Wie oben beschrieben, stellen Benutzernamespaces eine große Sicherheitsverbesserung dar. Ohne auf privilegierte Helfer angewiesen zu sein, ist es Benutzern, die auf dem Host nicht privilegiert sind, jedoch nur gestattet, ihre eigene UID einem Container zuzuordnen. Ein Standard-POSIX-System erfordert jedoch die Verfügbarkeit von 65536 UIDs und GIDs, um die volle Funktionalität zu gewährleisten.
LXC wird über einen einfachen Tastensatz konfiguriert. Zum Beispiel,
lxc.rootfs.path
lxc.mount.entry
Konfigurationsschlüssel für LXC-Namespaces mithilfe einzelner Punkte. Das bedeutet, dass komplexe Konfigurationsschlüssel wie lxc.net.0
verschiedene Unterschlüssel wie lxc.net.0.type
, lxc.net.0.link
, lxc.net.0.ipv6.address
und andere für noch feinere Funktionen verfügbar machen. körnige Konfiguration.
LXC wird als Standardlaufzeit für Incus verwendet, einen Container-Hypervisor, der darüber eine gut gestaltete und stabile REST-API bereitstellt.
LXC läuft auf jedem Kernel ab 2.6.32. Alles, was es erfordert, ist ein funktionsfähiger C-Compiler. LXC funktioniert auf allen Architekturen, die die notwendigen Kernel-Funktionen bereitstellen. Dazu gehören (ohne darauf beschränkt zu sein):
LXC unterstützt außerdem mindestens die folgenden C-Standardbibliotheken:
LXC hat sich immer auf eine starke Abwärtskompatibilität konzentriert. Tatsächlich wurde die API seit Version 1.0.0
nicht beschädigt. Haupt-LXC ist derzeit in Version 4.*.*
.
Das LXC-Projekt genießt einen guten Ruf bei der schnellen und effizienten Bearbeitung von Sicherheitsproblemen. Wenn Sie glauben, ein potenzielles Sicherheitsproblem gefunden zu haben, melden Sie es bitte per E-Mail an security (at) linuxcontainers (dot) org.
Weitere Details finden Sie unter
Wir freuen uns immer über neue Mitwirkende und stehen Ihnen bei Bedarf gerne mit Rat und Tat zur Seite. LXC folgt den Kernel-Codierungskonventionen. Das bedeutet, dass wir nur verlangen, dass jeder Commit eine Signed-off-by
Zeile enthält. Der von uns verwendete Codierungsstil ist identisch mit dem des Linux-Kernels. Eine ausführliche Einführung finden Sie unter:
und sollten sich auch die CONTRIBUTING-Datei in diesem Repo ansehen.
Wenn Sie aktiver werden möchten, ist es normalerweise auch eine gute Idee, im LXC-IRC-Kanal #lxc-dev auf irc.libera.chat aufzutauchen. Wir versuchen, die gesamte Entwicklung offen durchzuführen und die Diskussion neuer Funktionen oder Fehler erfolgt entweder in den entsprechenden GitHub-Ausgaben oder im IRC.
Wenn Sie darüber nachdenken, sicherheitskritische Beiträge oder wesentliche Änderungen vorzunehmen, ist es normalerweise eine gute Idee, zuerst die Entwickler anzupingen und zu fragen, ob eine PR akzeptiert wird.
LXC und die damit verbundenen Projekte halten sich strikt an ein semantisches Versionierungsschema.
Die Quelle für die neueste veröffentlichte Version kann jederzeit von heruntergeladen werden
Sie können den aktuellen Quellcode und den Änderungsverlauf online durchsuchen
Ohne Berücksichtigung verteilungsspezifischer Details ein einfaches
meson setup -Dprefix=/usr build
meson compile -C build
ist in der Regel ausreichend.
Wenn Sie feststellen, dass Sie Hilfe benötigen, bieten Ihnen die LXC-Projekte mehrere Optionen.
Wir unterhalten ein Diskussionsforum unter
wo Sie Unterstützung bekommen können.
Sie finden uns unter #lxc auf irc.libera.chat.
Sie können sich eines der beiden LXC-Mailinglisten-Archive ansehen und sich bei Interesse registrieren: