![[Photo of the Author]](../../common/images/Serge-Lozovsky.jpg)
original in en Serge Lozovsky
en to de Harald Radke
Serge arbeitet seit 20 Jahren mit Informationssystemen (als Programmier und Manager). Seine Erfahrungen sammelte er unter anderem in den Bereichen Internet-Technologien (5 Jahre), UNIX (9 Jahre) und im Bereich Künstlicher Intelligenz - Wissens- und Datenrepräsentation (4 Jahre).
Serge Lozovsky stellt eine Software vor, die er mit dem Ziel entwickelt hat, Unix Systeme sicherer zu machen. Das Programm ist nicht unter der GPL lizensiert, jedoch ist es möglich, die Software kostenlos zu nicht-kommerziellen Studienzwecken zu beziehen.
Ein Hauptproblem in Bezug auf die Sicherheit von Unix System stellt die Tatsache dar, dass der Superuser so ziemlich alles mit dem System tun kann, was er will. Darüberhinaus gibt es Programme (Daemons), welche mit den Rechten des Superusers arbeiten, als Beispiele seien hier genannt popd oder sendmail. Diese sind von aussen über das Netzwerk (Internet/Intranet) ansprechbar. Gibt es in solch einem Prgramm einen Programmierfehler, kann ein Angreifer, der mit diesem Daemon eine Verbindug aufbaut, diesen Fehler ausnutzen, und evtl. Kontrolle über den Rechner erlangen.
VXE(Virtual eXecuting Environment) sichert Unix Server gegen solche Angriffe über das Netz ab. Es beschützt Softwaresysteme, wie SMTP, POP, HTTP u.a. ab, die auf dem Server bereits installiert sind. Dabei ist es nicht notwendig, die bestehende Konfigurationen der Software zu ändern. Sie wird einfach nur gesichert
VXE schützt also den Rechner und bestimmte Untersysteme, welche mit den Rechten des Superusers laufen und potentiell Fehler beherbergen können. Also genau die Situation, die sich im Alltag immer wieder ergibt.
![[Illustration]](../../common/images/illustration133.jpg)
VXE schützt den Rechner und bestimmte Untersysteme, welche mit den Rechten des Superusers laufen und potentiell Fehler beherbergen können. Arbeitet das Programm im Superuser Modus, so stehen ihm alle Ressourcen des Betriebssystemes zu Verfügung. Es erzeugt für jedes Subsystem eine virtuelle Umegebung, eine VXE. In dieser sind dann nur noch die Ressourcen für das Subsystem verfügbar, dies es im normalen Betrieb benötigt. Unter den Begriff "Subsystem" fallen hierbei das zu Anfang gestartete Programm, sowie alle Unterprozesses, die von diesem erzeugt (forked) werden. Jeder Subprozess läuft in der gleichen VXE, wie sein Vaterprozess. Zugriffe auf jegliche Systemressourcen erfolgen durch Systemaufrufe des Betriebssystemes. Die VXE bestimmt nun, welche Systemaufrufe mit welchen Parametern jedem Subsystem zur Verfügung stehen. Beispielsweise kann festgelegt werden, auf welche Dateien mittels Leseoperationen zugegriffen und welche Programme ausgeführt werden können oder dass Netzwerkaktionen verboten sind (wie zum Beispiel im Fall eines POP Servers, der dann zwar Anfragen über das Netz bearbeiten, aber keine neuen Verbindungen aufbauen kann). Diese Beschränkungen können dann nicht einmal von Programmen unterlaufen werden, die mit Superuser Rechten laufen.
Die Einschränkungen können beliebig ausgefeilt sein. Sollte ein Angreifer nun Kontrolle über ein solches Subsystem erlangen, kann er nicht die gängigen Methoden zum Ausspionieren anwenden oder das System lahmlegen. Alles, was er, zumindest theoretisch, noch tun kann, ist, Einfluss auf den Ablauf des geknackten Subsystems zu nehmen (was auch nicht so einfach ist). Das Betriebssystem selbst und alle anderen Subsysteme bleiben hiervon auf jeden Fall unberührt. Gängige Methoden bedeutet hier, dass der Angreifer sich Superuser Rechte aneignet und über die Shell die normalen Werkzeuge, wie etwa Texteditoren, Kopierprogramme u.ä. verwendet. Ohne diese Programme aber ist er aufgeschmissen. Betrachtet man wieder den POP Server, so braucht dieser für den Betrieb keine Kopierprogramme, sodass der Zugriff auf diese in der jeweiligen VXE unterbunden wird.
Genauer gesagt schirmt VXE das System und seine Subsysteme vor Subsystemen ab, in die ein Angreifer eingestiegen ist (diese Subsysteme stehen dabei immernoch unter der Kontrolle der entsprechenden VXE). Nebenbei wird dabei auch das Subsystem selbst geschützt, wie oben erklärt worden ist. Zur Vereinfachung wird im nachfolgenden Text einfach gesagt, dass VXE die Subsysteme absichert.
VXE Description (VXED) ist ein kleines LISP Progamm (eine Menge von Funktionen), welches eine deklarative Beschreibung der zulässigen Parameter der verschiedenen Systemaufrufe verwendet. VXED wird in den Kernel geladen, von wo aus es die die Parameter von Systemaufrufe der angegebenen Subsysteme kontrolliert. VXEDs sind also dynamisch ladbare Module, welche von einem kleinen LISP Interpreter, der im Kernel inegebettet wird, abgearbeitet werden. In der gegenwärtigen Version von VXE ist dieser Interpreter vxelisp, welcher aus RefLisp (von Bill Birchm [email protected]) heraus entwickelt worden ist. vxelisp hat eine neue interne Darstellungsart von langen Zeichenketten, sowie einen kompletten Satz an Zeichenketten und Bit Funktionen. Die Kernelversion von vxelisp ist in der Lage, mehrere VXEDs gleichzeitig zu handhaben.
Es gibt zwei Arten der Aktivierung von VXEDs, die explizite und die implizite (automatische) Aktivierung. Explizit wird VXED aktiviert durch das Programm vxe. Parameter hierbei sind der Pfadname der VXED, sowie Pfad und Parameter des Programmes, welches in der VXE laufen soll. Bei der automatischen Aktivierung lädt das Programm vxed alle benötigten VXEDs in den Kernel. Jede VXED hat ein eigenes Muster für die Aktivierung. Während des Startvorganges eines Programmes (exec) überprüft der Kernel den Pfad des Programmes anhand dieser Muster, die jeweilige VXED wird aktiviert. Durch diese Art der Ausführung kann die Absicherung zum Beispiel durch den Aufruf eines beliebigen Prgrammes aus einem angegebenen Verzeichnis (und dessen Unterverzeichnissen) heraus aktiviert werden, wie etwa der Schutz von CGI Skripten, die von Benutzern erstellt worden sind. Für das Heimatverzeichnis eines jeden Benutzers können so VXEDs definiert werden.
Jede beliebig komplexe VXED kann per Hand erstellt werden, unter der Verwendung aller Möglichkeiten, die vxelisp bietet. Allerdings ist kein Administrator genötigt, LISP zu lernen und zu verwenden. VXE kann als selbständig lernendes System betrachtet werden. Das VXE Entwicklungssystem startet VXE im Trace Modus.
In diesem Modus werden beim Durchlauf Beschreibungen der erlaubten (verwendeten) Systemaufrufe ausgegeben. Das Erstellen und Ändern einer VXED wird durch eine WWW Schnittstelle ermöglicht. Das Entwicklungssystem kennt zwei Arten von VXEDs: strikte und das Dateisystem betreffende. Die strikte VXED beschreibt explizit alle erlaubten Systemaufrufe. Dagegen beschreibt die Dateisystem VXED Lese-, Schreib- und Ausführungberechtigungen für einen bestimmten Pfad. Die angegenbenen Beschränkungen betreffen nur Systemaufrufe des Dateisystemes, während alle anderen Aufrufe zugelassen sind. Wurde eine VXED für ein bestimmtes Subsystem erstellt, läuft sie im soft Modus. Alle Verletzungen der Beschränkungen werden zwar protokolliert, Systemaufrufe aber durchgeführt. Das VXE Entwicklungssystem kann die VXED mittels dieser Informationen automatisch erweitern.
Natürlich können notwendige Änderungen in einer VXED auch manuell mit dem VXED Editor realisiert werden. Verletzungen können durch Aktivitäten eines Angreifers oder durch eine Abweichung im Verhalten des Subsystemes aus verschiedenen Gründen verursacht werden. Der VXE Administrator überprüft die Protokolle mit Hilfe des Entwicklungssystemes und entscheidet dann, ob ein Erweiterung sinnvoll ist. Treten keine Verletzungen auf, so kann die VXED in den production Modus gebracht werden. In diesem werden alle Verletzungen der Beschränkungen protokolliert und Systemaufrufe unterbunden (failure). Auch hier können die Protokolle zum Auffinden von Angreifern oder der Justierung der VXED verwendet werden.
Aus Sicherheitsgründen können Arbeiten an VXEs nur vom Superuser und ausserhalb einer VXE durchgeführt werden.
VXE nimmt wie folgt Einfluss auf die Systemleistung: Läuft ein Programm nicht innerhalb einer VXE, so werden bei jedem Systemaufruf zwei Assemblerbefehle zusätzlich ausgeführt (Es wird geprüft, ob VXE über den aktuellen Prozess wacht und ein Sprung ausgeführt, falls dies nicht der Fall ist). Für jeden exec Systemaufruf testet eine kleine C Subroutine, ob ein entsprechende VXED im Kernel vorhanden ist. Für den Ablauf eines Programmes in einer VXE testen einige Zeilen C Code, ob eine Korrektheitsprüfung für die Parameter notwendig ist. Einige Aufrufe können in der VXED so gekennzeichnet werden, dass sie nicht überprüft werden (standardmäßig gilt dies zum Beispiel für read und write Operationen). Nur die verbleibenden Aufrufe werden mittels kleiner LISP Funktionen überprüft. Diese Funktionen befinden sich in der VXED und können relativ einfach vom Administrator überwacht werden.
VXE Support: [email protected]
VXE Homepage: http://www.intes.odessa.ua/vxe