Konzepte und Techniken virtueller Maschinen und Emulatoren (virme) Friedrich-Alexander-Universität Erlangen-Nürnberg. Sebastian Harl

Transkript

1 Konzepte und Techniken virtueller Maschinen und Emulatoren (virme) Friedrich-Alexander-Universität Erlangen-Nürnberg Sebastian Harl 06. Juni 2007 Zusammenfassung Linux-VServer ist eine Form der Betriebssystem-Virtualisierung für den Linux-Kernel. Ein laufendes Linux-System wird in mehrere Partitionen aufgeteilt. Die Implementierung baut weitestgehend auf bestehender Infrastruktur auf und erweitert diese wo nötig. Diese Arbeit liefert einen Überblick über die Implementierung sowie das Management von Gast- Systemen. Inhaltsverzeichnis 1 Einführung Was ist Linux-VServer Das Projekt Implementierung Bestehende Infrastruktur Kontext Trennung Prozess Kontexte Netzwerk Kontexte Chroot Barrier CPU Isolation Netzwerk Isolation Linux-VServer Management (Überblick) Erzeugen eines Linux-VServers Verwalten eines Linux-VServers Ähnliche Projekte 9 1

2 1 EINFÜHRUNG 1 Einführung Virtualisierung ist seit vielen Jahren eine gebräuchliche Methode, um Ressourcen eines Rechners besser zu nutzen, oder, um verschiedene Software, die auf einem System läuft, voneinander abzuschirmen. Ein Großteil der bestehenden Lösungen nutzt Emulation, um Hardware nachzubilden, auf denen das virtualisierte System laufen kann. Das hat den Vorteil, dass beliebige Gast-Betriebssysteme darauf ausgeführt werden können. Als Nachteil erkauft man sich teuren Overhead, der für die Emulation benötigt wird. Linux-VServer setzt hierbei statt dessen auf Betriebssystem-Virtualisierung mittels Partitionen. 1.1 Was ist Linux-VServer Linux-VServer richtet sich an Einsatz-Zwecke, bei denen im Host- sowie in allen Gast- Systemen das gleiche Betriebssystem laufen kann. Der hauptsächliche Augenmerk liegt darauf, dass verschiedene Anwendungen voneinander getrennt und gegeneinander abgesichert auf der gleichen Maschine laufen können. Da man hierbei auf Emulation verzichtet, entsteht sehr wenig Overhead. Umgesetzt wird dieses Ziel, indem sogenannte Security Contexts eingeführt wurden, die eine laufende Instanz eines Linux-Kernels in größtenteils unabhängige Virtual Private Servers aufteilen. Damit ist als Gast-System nur Linux möglich - es können jedoch verschiedene Distributionen oder Versionen davon gleichzeitig verwendet werden. Die Implementierung besteht aus einem Kernel Patch, welcher vorhandene Infrastruktur ausbaut und, wenn nötig, erweitert. Die Einführung der Security Contexts und deren dynamische Erzeugung und Zerstörung zur Laufzeit zogen eine Erweiterung des Syscall- Interfaces nach sich. Um diese Erweiterungen nutzen zu können, sind Userspace-Tools, wie util-vserver 1 von Enrico Scholz, nötig. 1.2 Das Projekt Die Anfänge des Projekts gehen in Etwa auf die zweite Hälfte des Jahres 2001 zurück als Jacques Gelinas einen Patch auf der Linux-Kernel Mailing List vorschlug 2, der die Ausführung von mehreren virtuellen Servern auf einem System ermöglicht. Später wurde das Projekt von Herbert Pötzl übernommen, der bis heute die Leitung behalten hat. Am 1. November 2003 wurde die Version 1.0 freigegeben. Zum Zeitpunkt der Erstellung dieses Dokuments (Juni 2007) sind die Versionen 2.2.x sowie 2.3.x aktuell, wobei ungradzahlige Versionsnummern die Entwicklungsversion kennzeichnen. Wie es für OpenSource-Projekte üblich ist, gibt es eine Reihe von verschiedenen Ressourcen zu dem Projekt. Die hauptsächliche Informationsquelle stellt das Wiki auf der Homepage 3 dar. Zusätzlich gibt es die Möglichkeit, über die Mailing Liste vserver@list.linuxvserver.org oder den IRC-Channel #vserver auf irc.oftc.net direkten Kontakt mit vielen Benutzern oder einigen Entwicklern aufzunehmen

3 2 IMPLEMENTIERUNG 2 Implementierung Aktuelle Kernel-Versionen bieten bereits viele Sicherheits-Features, welche von Linux- VServer verwendet werden, um die gewünschten Ziele zu erreichen. Darauf aufbauend wurde der Kernel um einige Features erweitert. Die wichtigsten Bestandteile der Linux- VServer Architektur werden im folgenden Abschnitt erläutert. 2.1 Bestehende Infrastruktur Linux Capabilities. Dieses auf den POSIX Capabilities basierende System teilt die Rechte des Systemverwalters (root) in mehrere voneinander unabhängige Berechtigungen auf. Diese werden einem Thread durch drei Bitmaps zugeordnet. Die effective Capabilities legen fest, welche privilegierten Operationen ein Thread ausführen darf. Eine Obermenge davon, die permitted Capabilities, definiert die Menge der Capabilities, welche ein Thread annehmen darf. Damit können bestimmte Rechte temporär abgelegt werden, indem sie aus dem effective Set entfernt und später wieder hinzugefügt werden. Eine Berechtigung, die aus dem permitted Set entfernt wurde, kann durch den Prozess nicht wieder hinzugefügt werden. Die Menge der inheritable Capabilities kann an Kind-Prozesse weitergegeben werden. Detailierte Informationen zu diesem System finden sich in der capabilities(7) Manpage sowie in /usr/include/linux/capability.h, worin die vorhandenen Capabilities aufgeführt sind. Resource Limits. Mit diesem System lassen sich Prozessen Limits für bestimmte Ressourcen auferlegen. Man unterscheidet dabei zwischen Soft- und Hard-Limits. Erstere definieren die Werte, die aktuell von einem Thread nicht überschritten werden dürfen, während Zweitere eine Obergrenze für dieses tatsächliche Limit darstellen. Ähnlich wie bei den Capabilities darf das Soft-Limit in den Grenzen des Hard-Limits beliebig und das Hard-Limit nur nach Unten gesetzt werden. Detaillierte Informationen findet man in den ulimit(3), sowie getrlimit(2) und setrlimit(2) Manpages. Datei Attribute. Dieses ursprünglich nur im ext2-dateisystem vorhandene Feature erlaubt das Setzen von Attributen, welche bestimmte Eigenschaften einer Datei festlegen. Mittlerweile werden Datei Attribute von allen großen Dateisystemen implementiert. Informationen zu den vorhandenen Attributen findet man in der chattr(1) Manpage. chroot. chroot erlaubt das Ändern des Root-Dateisystems. Damit werden alle Lookups im Dateisystem relativ zu der angegebenen neuen Wurzel durchgeführt. Obwohl die im Linux-Kern bestehende Implementierung nicht sehr sicher ist (vgl. Abschnitt 2.5 auf Seite 6), kann man damit verschiedene Prozesse im Bezug auf das Dateisystem voneinander isolieren. 2.2 Kontext Trennung Um die parallel auf der gleichen Hardware laufenden Security Contexts voneinander zu trennen, mussten einige Änderungen am Kernel vorgenommen werden, welche die Einführung von Kontexten ermöglichen. Damit sollen Prozesse aus unterschiedlichen Kontexten voreinander versteckt werden und ungewollte Interaktion zwischen ihnen verhindert werden. 3

4 2.3 Prozess Kontexte 2 IMPLEMENTIERUNG Linux VServer Architecture context 1 (spectator) context 0 context 1000 context 1001 /, /bin, /home,... /, /bin, /home,... /, /bin, /home,... eth0 procfs IPC, SHM,... eth0 procfs IPC, SHM,... eth0 procfs IPC, SHM,... kernel hardware (C) 2006 Sebastian Harl <sh@tokkee.org> Abbildung 1: Linux-VServer Architektur Abbildung 1 zeigt eine schematische Darstellung der Linux-VServer Architektur. Alle laufenden Kontexte haben über den Kernel direkten Zugriff auf die Hardware, während die Sichtbarkeit eines Prozesses und Interprocess Communication (IPC) auf einen Kontext beschränkt sind. Der direkte Zugriff auf System-Informationen über das proc-dateisystem ist ebenfalls eingeschränkt, um es einem Benutzer innerhalb eines Kontexts nicht zu ermöglichen, auf Informationen, die andere Kontexte betreffen, zuzugreifen. Jeder Kontext hat außerdem nur auf einen ihm zugeordneten Teil des Dateisystems Zugriff, so dass jeder Kontext sein eigenes Root-Dateisystem besitzt. Für das Bootstrapping eines Systems wurde der Kontext 0 eingeführt, mit dem ein System standardmäßig startet. Aus diesem heraus können weitere Kontexte erstellt werden. Eine Verschachtelung, d.h. die rekursive Partitionierung eines Kontexts, wird aktuell nicht unterstützt. 2.3 Prozess Kontexte Die Einführung der Kontext Trennung verlangte eine Anpassung von bestehenden Datenstrukturen, damit diese einem Kontext zugeordnet werden können und identische UIDs verschiedener Kontexte voneinander unterschieden werden können. Dafür wurden neue Datenstrukturen eingeführt, die einen Kontext beschreiben. Listing 1 auf der nächsten Seite zeigt das struct vx info, welches allgemeine Informationen über einen Kontext enthält. Neben Verwaltungsdaten, die den Kontext näher beschreiben (ID, Name, etc.), enthält es einige Referenzen auf weitere Strukturen, welche weitere Teilbereiche eines Kontext (Scheduling, Namensräume, etc.) beschreiben. Da einige Programme davon ausgehen, dass es einen init-prozess mit der Process ID (PID) 1 gibt, kann in jedem Kontext die PID eines beliebigen Prozesses auf die PID 1 abgebildet werden (vx initpid-feld des struct vx info). Dieser fake init Prozess kann auf verschiedene Art und Weise bereit gestellt werden. Einen Überblick über die Methoden findet man unter Weiterhin wurde für jeden Kontext eine Capability Maske eingeführt, die die in Abschnitt 2.1 auf der vorherigen Seite beschriebenen Linux Capabilities Kontext-bezogen auf 4

5 2.4 Netzwerk Kontexte 2 IMPLEMENTIERUNG Listing 1: struct vx info (aus include/linux/vserver/context.h) 1 struct vx info { 2 struct list head v x l i s t ; / l i n k e d l i s t o f c o n t e x t s / 3 xid t vx id ; / c o n t e x t i d / 4 atomic t vx refcount ; / r e f c o u n t / 5 struct vx info vx parent ; / parent c o n t e x t / 6 7 struct namespace vx namespace ; / p r i v a t e namespace / 8 struct f s s t r u c t vx fs ; / p r i v a t e namespace f s / 9 uint64 t vx flags ; / c o n t e x t f l a g s / 10 uint64 t vx bcaps ; / bounding caps ( system ) / 11 uint64 t vx ccaps ; / c o n t e x t caps ( v s e r v e r ) / pid t vx initpid ; / PID o f f a k e i n i t p r o c e s s / struct vx limit limit ; / v s e r v e r l i m i t s / 16 struct vx sched sched ; / v s e r v e r s c h e d u l e r / 17 struct vx cvirt cvirt ; / v i r t u a l / b i a s s t u f f / 18 struct vx cacct cacct ; / c o n t e x t accounting / char vx name [ 6 5 ] ; / v s e r v e r name / 21 } ; die angegebene Menge beschränkt. Zur Vereinfachung wird der Kontext des Host-Systems (Kontext 0), im Hinblick auf Prozess-Isolierung, genauso behandelt wie jeder andere Kontext. Um die Möglichkeit zu schaffen, einen Überblick über das gesamte System zu erhalten wurde der sogenannte Spectator Kontext eingeführt. Dieser ermöglicht einen lesenden Zugriff auf alle im System laufenden Prozesse (vgl. Abb. 1 auf der vorherigen Seite). Alle Kontexte greifen auf die gleiche Datenbank für PIDs zu. Somit ist jede PID im gesamten System eindeutig. 2.4 Netzwerk Kontexte Damit Prozesse innerhalb eines Kontextes nur auf dem Kontext zugeordnete Netzwerk- Adressen zugreifen können, sind einige Anpassungen am Netzwerk Subsystem nötig. Linux- VServer verzichtet dabei auf die Einführung von virtuellen Inferfaces, um den Overhead möglichst gering zu halten. Dabei werden die Routing- und IPTables-Einträge von allen Kontexten gemeinsam verwendet. Deshalb können diese Einstellungen nur aus dem Host- System heraus geändert werden. Damit reicht die Performanz dieser Implementierung aber an die eines normalen Linux-Systems heran (siehe [3]). Diese Netzwerk Kontexte werden durch eine spezielle Behandlung von beispielsweise der localhost-adresse und der IPADDR ANY-Adresse durchgesetzt. Dazu werden alle Pakete mit einer ID des jeweiligen Kontexts markiert. Außerdem wurde der Netzwerk-Stack angepasst, damit diese Pakete nur vom richtigen Gast-System empfangen werden können. Im Gegensatz zu den Prozess-Kontexten sind die Netzwerk-Konfigurationen der verschiedenen Gast-Systeme im Host-System sichtbar. Daher müssen Daemons im Host- System so konfiguriert werden, dass sie sich nicht an die Netzwerk-Adressen der Gast- Systeme binden. Innerhalb der Gast-Systeme sind jedoch keine solchen Vorkehrungen nötig. 5

6 2.5 Chroot Barrier 2 IMPLEMENTIERUNG 1 chdir ( / ) ; 2 fd = open( /, ORDONLY) ; 3 4 mkdir( f o o ) ; 5 chroot ( f o o ) ; 6 7 fchdir ( fd ) ; 8 9 for ( i = 0 ; i < 4 2 ; ++i ) 10 chdir (.. ) ; chroot (. ) ; exec ( / bin / sh ) ; Listing 2: mit fchdir() aus einem chroot ausbrechen Listing 3: Chroot Barrier (aus fs/namei.c) 1 i f (IS BARRIER( inode ) &&! vx check ( 0, VXADMIN) ) { 2 vxwprintk ( 1, xid=%d did h i t the b a r r i e r., 3 vx current xid ( ) ) ; 4 return EACCES; 5 } 2.5 Chroot Barrier Jedes Gast-System besitzt sein eigenes Root-Dateisystem. Dies wird prinzipiell durch einen Aufruf an chroot() umgesetzt. Der chroot() Systemcall hat jedoch eine Reihe von Problemen, die alle darauf hinauslaufen, dass aus einem chroot ausgebrochen werden kann, wenn man root-rechte besitzt. Listing 2 zeigt schematisch ein Beispiel einer Methode, um aus einem chroot auszubrechen. Diese Methode nutzt aus, dass offene Datei-Deskriptoren bei dem chroot()-systemcall nicht geschlossen werden. Dadurch ist der fchdir()-aufruf in Zeile 7 erfolgreich, obwohl er außerhalb des neuen chroot führt. Da durch den chroot()-aufruf in Zeile 5 das alte Root-Verzeichnis vergessen wurde, bewegt man sich mit den chdir()-aufrufen in Zeile 10 nach außerhalb des alten Root-Verzeichnisses und kann sich mit dem chroot()-aufruf in Zeile 12 aus dem alten chroot befreien. In aktuellen Linux-VServer Versionen wird dieser Möglichkeit entgegengewirkt, indem das Dateisystem-Attribut Chroot Barrier angeboten wird, welches verhindert, dass ein bestimmtes Verzeichnis überschritten wird. Dieses Attribut kann mit dem Befehl setattr --barrier <pfad> gesetzt werden. Sinnvollerweise geschieht dies für das Parent-Verzeichnis des Root-Dateisystems jedes Gast-Systems. Listing 2.5 zeigt die Überprüfung dieses Attributes, wie sie bei der Überprüfung der Berechtigungen im Dateisystem-Subsystem des Kernels passiert. Mit dieser Änderung und einer korrekt gesetzten Chroot Barrier schlägt bei dem in Listing 2 gezeigten Beispiel der chdir()-aufruf in Zeile 10 fehl, sobald die Inode erreicht würde, für die das Barrier- Attribut gesetzt ist. 2.6 CPU Isolation Ursprünglich wurde Linux-VServer dazu entwickelt, dass sich verschiedene Prozesse friedlich die verfügbaren Ressourcen eines Systems teilen. Jedoch macht es in manchen An- 6

7 2.7 Netzwerk Isolation 3 LINUX-VSERVER MANAGEMENT (ÜBERBLICK) wendungsfällen Sinn, dass ein Gast-System auf eine angegebene Ressourcen-Ausnutzung limitiert wird. Um die CPU-Aufteilung zwischen den Gast-Systemen zu regeln, wurde ein Token Bucket Filter (TBF) vor den Standard O(1) CPU-Scheduler des Linux-Kernels gesetzt. Ein Token Bucket Filter basiert auf einem Behältnis welches mit Tokens gefüllt ist. Dieses Behältnis wird mit einer bestimmten Rate bis zu einer maximalen Füllmenge befüllt. Zu jeder Zeiteinheit, in der ein Prozess, der dem Kontext zugeordnet ist, läuft, wird ein Token entfernt. Sind keine weiteren Tokens mehr verfügbar, so wird der Kontext in eine Warteschlange eingereiht, bis das Behältnis eine vorgegebene minimale Füllmenge wieder erreicht hat. Es gibt zwei Methoden, die kombiniert eingesetzt werden können. Zum einen kann eine sogenannte Reservation Rate definiert werden. Diese gibt an, mit welcher Rate das Behältnis wieder befüllt wird. Außerdem werden Kontexte mit einer definierten Reservation anderen Kontexten bei der CPU-Vergabe vorgezogen. Damit lässt sich ein fester Anteil an der Nutzung der CPU festlegen. Zum anderen kann ein Share festgelegt werden, welches angibt, welcher Teil der verbleibenden CPU-Zeit zugeteilt wird. 2.7 Netzwerk Isolation Das gerade beschriebene Konzept lässt sich prinzipiell auf alle Arten von Ressourcen anwenden. Aufbauend auf der Hierarchical Token Bucket (HTB) Disziplin der Traffic Control (tc) Einheit des Linux-Kernels wird eine Aufteilung der Netzwerk-Ressourcen unter den Gast-Systemen implementiert. Wie im Fall der CPU kann eine Reservation Rate und ein Share angegeben werden. Alle Pakete, die von einem Gast-System verschickt werden, werden über eine Markierung mit der Kontext-ID eindeutig dem Gast zugeordnet. Damit können die Pakete in der Netzwerk-Schicht des Kernels dem Gast angerechnet werden und die konfigurierten Raten durchgesetzt werden. Prinzipiell unterscheidet man zwischen drei Zuteilungsmöglichkeiten: Begrenzte Rate: Es wird nur eine Reservation Rate ohne Share definiert. Damit kann jedes Gast-System maximal das ihm zugeordnete Limit ausschöpfen; überschüssige Ressourcen gehen verloren. Fair Best Effort: Es wird nur ein Share angegeben, womit jedem Gast-System anteilig die Ressourcen zugesprochen werden; alle überschüssigen Ressourcen können verwendet werden. Mittelweg: Es wird sowohl eine Reservation Rate als auch ein Share angegeben, wodurch einem Gast eine gewisse Auslastung zugesprochen wird, überschüssige Ressourcen aber dennoch verwendet werden können, da sie an die Gäste anteilig weitergegeben werden. 3 Linux-VServer Management (Überblick) Der folgende Abschnitt gibt einen kurzen Überblick über das Management von Linux- VServer Gast-Systemen unter Verwendung der util-vserver. 7

8 3.1 Erzeugen eines Linux-VServers 3 LINUX-VSERVER MANAGEMENT (ÜBERBLICK) 3.1 Erzeugen eines Linux-VServers Zur Erzeugung eines neuen Gast-Systemes müssen einige Konfigurationsdateien geschrieben werden, sowie das eigentlich System in ein Unterverzeichnis des Dateisystems des Hosts installiert werden. Die Erzeugung der Konfiguration ist unabhängig von der im Gast-System verwendeten Distribution. Die Installation des Systems hängt jedoch stark davon ab. util-vserver unterstützt einige weit verbreitete Installationsmöglichkeiten, darunter unter anderem debootstrap für Debian Systeme oder apt-rpm für Fedora / RedHat. Listing 4: Erzeugung eines Debian Gast-Systems 1 v s e r v e r t e s t 1 b u i l d m d e b o o t s t r a p hostname t e s t 1. domain. t l d \ 2 i n t e r f a c e eth0 : / 2 4 c o n t e x t 42 d s a r g e Listing 5: Erzeugung eines Redhat Gast-Systems 1 v s e r v e r t e s t 2 b u i l d m apt rpm hostname t e s t 2. domain. t l d \ 2 i n t e r f a c e eth0 : / 2 4 c o n t e x t 43 d f c 1 Als sehr grundsätzliche Methode wird weiterhin die Erstellung eines sogenannten Skeleton unterstützt. Hierbei werden die Konfigurationsdateien und eine Basis-Verzeichnisstruktur erstellt. Aufbauend darauf lassen sich dann nahezu beliebige Installationsmöglichkeiten nutzen. Listing 6: Erzeugung eines Skeleton 1 v s e r v e r t e s t 3 b u i l d m s k e l e t o n hostname t e s t 3. domain. t l d \ 2 i n t e r f a c e eth0 : / 2 4 c o n t e x t 44 Neben den hier gezeigten Beispielen werden einige andere Konfigurationsparameter unterstützt, die in der Hilfe des vserver Befehles dokumentiert sind. 1 v s e r v e r b u i l d help Listing 7: Hilfe zur Erzeugung von Gast-Systemen 3.2 Verwalten eines Linux-VServers Beim Starten eines Linux-VServer Gast-Systemes werden die benötigten virtuellen Umgebungen (Namespaces, Kontext, etc.) erstellt, alle benötigten Dateisysteme eingehängt, die für den Gast geltenden Beschränkungen aktiviert und das System mit dem (fake-)init Prozess gestartet. 1 v s e r v e r <name> s t a r t Listing 8: Starten eines Gast-Systems Soll ein Gast heruntergefahren werden, so muss das laufende System beendet werden sowie die beim Starten durchgeführten Aktionen rückgängig gemacht werden. 1 v s e r v e r <name> stop Listing 9: Stoppen eines Gast-Systems Die genaue Implementierung der start und stop Operationen hängen vom verwendeten fake-init-schema und der Distribution im Gast-System ab. 8

9 LITERATUR Besonders für administrative Aufgaben bietet es sich an, eine Möglichkeit zu haben, direkt aus dem Host-System heraus auf das Gast-System einzuwirken. Dafür kann aus dem Host-System heraus ein Kontext-Wechsel durchgeführt werden. 1 v s e r v e r <name> e n t e r exec Listing 10: Betreten eines Gast-Systems 4 Ähnliche Projekte OpenVZ ist eine OpenSource Untermenge des kommerziellen Virtuozzo. Es verfolgt einen ähnlichen Ansatz wie Linux-VServer, unterscheidet sich jedoch deutlich in der Implementierung. FreeVPS ist ein Fork von Linux-VServer. FreeBSD Jails können eine einfache Partitionierung des Systems vornehmen - besonders im Bezug auf das Dateisystem. Im Vergleich zu Linux-VServer besitzt es jedoch deutlich weniger Features. Solaris Zones sind eine Betriebssystem-Virtualisierungslösung für Solaris. Konzeptuell sind sie Linux-VServer relativ ähnlich. Literatur [1] Herbert Pötzl, et.al.: Linux-VServer Paper, aufgerufen am [2] Benedikt Böhm, et.al.: Secure chroot Barrier, chroot Barrier, aufgerufen am [3] Stephen Soltesz, Herbert Pötzl, Marc E. Fiuczynski, Andy Bavier, Larry Peterson: Container-based Operating System Virtualization: A Scalable, High-performance Alternative to Hypervisors, mef/research/vserver/paper.pdf, aufgerufen am