HP-LX tritt an, um Crackern das Leben schwerer zu machen. Im Gegensatz zu einem normalen Linux haben sie bei HP-LX selbst nach einem erfolgreichen Angriff keine Kontrolle über den Rechner.

Hewlett-Packard entwickelt derzeit eine auf Sicherheit optimierte Linux-Version. Der modifizierte Kernel 2.4 stellt eine Reihe neuer Sicherheitsdienste bereit: Er schottet zum Beispiel Prozesse vom Rest des Systems ab, indem er sie in Compartments sperrt. Er überwacht dabei alle Interprozess-Kommunikationswege. Er schützt Dateien vor Änderungen, selbst Root hat keine Sonderrechte mehr. Und durch das erweiterte Auditing kann der Admin mysteriösen Vorgängen besser auf den Grund gehen.

HP-LX basiert derzeit auf Red Hat Linux 7.1, getestet wurden die Betaversion und eine Vorabversion der Release-CD.

Auch ein herkömmliches Linux kann durch eine ordentliche Konfiguration oder durch eine Firewall schon recht gut geschützt werden. Problematisch bleiben aber die Dienste, die trotzdem noch erreichbar sein müssen. Ein Implementierungsfehler im Webserver kann trotz einer Application-Level-Firewall zu einem Einbruch führen, solange der Exploit einen legalen HTTP-Request nutzt. Wenn der Dienst dann auch noch mit Root-Rechten läuft, ist das angegriffene System vollständig in der Hand der Angreifer.

Mit den klassischen Mechanismen kann der Admin beispielsweise Folgendes dagegen unternehmen:

• Changeroot-Umgebungen einsetzen
• Teile des Systems Read-only setzen
• Ordentliche Zugriffsrechte vergeben und nicht einfach die Einstellungen der Distribution lassen
• Iptables/Ipchains auch auf dem lokalen System nutzen
• Alle Sicherheits-Patches einspielen und schnell auf Cert-Advisories reagieren

Mit Board-Mitteln lassen sich aber beispielsweise die normalen IPC-Mechanismen nicht schützen. Ein Angreifer, der seinen eigenen Code auf dem System erfolgreich ausführt, sieht auch alle laufenden Prozesse und alle existierenden Netzwerkverbindungen. Dies öffnet ihm weitere Angriffspunkte, auch wenn das System entsprechend der obigen Maßnahmen sinnvoll geschützt ist.

Falls er Root-Rechte erreicht, kann ein Eindringling bei einem normalen Linux auch Schutzmechanismen wieder abschalten. Der Angreifer könnte etwa die Paketfilterregeln deaktivieren oder die Schreibrechte an wichtigen Dateien für alle freigeben.

Compartment als Sandbox

An dieser Stelle greift das Konzept der Compartments von HP-LX (siehe Abbildung 1). Unter Compartments sind abgeschlossene Ablaufumgebungen zu verstehen, gewissermaßen ein Rechner im Rechner – Java-Programmierern und Benutzern von Personal Firewalls aus der Windows-Welt ist der Begriff Sandbox wahrscheinlich geläufiger. In einem Compartment lassen sich folgende Dinge einschränken:

• Wie bei Firewalls können Zugriffe auf dieses Compartment eingeschränkt werden. Anders als bei Firewalls greifen die Einschränkungen hier aber für alle IPC-Mechanismen: Shared Memory, Semaphore, Messages, Unix-Domain-Sockets, Raw Sockets und auch normale Internet-Sockets.
• Der Zugang zum Dateisystem aus dem Compartement heraus lässt sich einschränken. Diese Regeln gelten zusätzlich zu den Dateizugriffsrechten. Sie unterscheiden das Lesen, Schreiben und Anhängen; der Zugriff lässt sich auch ganz sperren.
• In einem Compartment kann der Wechsel der User-ID zu Root (etwa durch S-Bit-Programme oder mit »su«) abgestellt werden.

Wichtig ist, dass es zur Verwaltung der Compartments nicht ausreicht, Root zu sein. Hierfür gibt es zwei zusätzliche Flags, die nicht an einer User-ID, sondern am gestarteten Prozess hängen. Diese privilegierten Prozesse können ihre zusätzlichen Rechte an ihre Kinder weitergeben, ein modifizierter Init-Prozess startet über die Inittab die ersten dieser privilegierten Prozesse.

Abbildung 1: Compartments teilen einen Rechner in unterschiedliche Bereiche ein. Für jedes Compartment lässt sich festlegen, mit welchem anderen Compartment oder mit welchen Rechnern es Verbindungen aufnehmen darf.

An der Wurzel gepackt

Idealerweise verbindet man diesen Mechanismus noch mit einer Changeroot-Umgebung (siehe Kasten “Changeroot”). Die mitgelieferten Werkzeuge unterstützen den Administrator beim Initialisieren einer solchen Umgebung, da dies meist in einer ziemlichen Fummelei endet: Welche Bibliothek fehlt jetzt schon wieder? Die Werkzeuge können die Detailarbeit zwar nicht vollständig ersetzen, aber immerhin erleichtern.

Wenn es ein Angreifer schafft, durch eine bekannte Lücke einen in einem Compartment laufenden Prozess zu kompromittieren, kann dieser Prozess nicht mehr das gesamte Dateisystem sehen (Changeroot und Dateizugriffsrechte). In seinem Bereich sind auch die Schreibrechte eingeschränkt.

Nur die Nutzdateien und Logfiles, die in diesem Compartment erzeugt werden, sollten beschreibbar sein – der Rest ist dann vor dem Angreifer geschützt. Das gilt auch für Prozesse mit UID Null. Für den Prozess sieht es eher so aus, als liefe er von einer CD-ROM, wenn dem Compartment nur lesende Rechte gegeben wurden. Der Prozess kann zwar aus dem Kernel die Tabelle der laufenden Prozesse und offenen Netzwerkverbindungen abrufen, er wird allerdings nur die sehen, die zu seinem Compartment gehören.

chroot /compt/web /bin/apachectl start

Sollte der Prozess für einen Portscan missbraucht werden, wird auch dieser ins Leere laufen: Es sind ausschließlich jene Internet-Verbindungen möglich, die in den Regeln explizit erlaubten wurden – falls dieses Compartment überhaupt Verbindungen nach außen aufbauen darf. Neben Internet-Verbindungen unterliegen auch die Verbindungen in andere Compartments den Regeln.

Auditing im Kernel

Die Compartments werden in HP-LX durch ein Kernel-Level-Auditing ergänzt. Dieser Mechanismus kann sehr wertvoll für das Debugging sein, dient aber eigentlich eher der Beweissicherung. Die Schnittstellen im Kernel protokollieren Betriebssystemaufrufe wie »open()« oder »connect()«. Um diese Informationen auszulesen, gibt es dann ein spezielles Device »/dev/auditr«. Hinzu kommt noch ein Audit-Daemon, der auch wieder in einem eigenen Compartment läuft. Er holt diese Daten aus dem Kernel ab und schreibt sie in eine Datei. Diese Trails lassen sich dann mit weiteren Werkzeugen auswerten.

Für das Debugging sind diese Daten recht hilfreich, da sie der Ausgabe von Strace ähneln. Gerade bei Chroot-Umgebungen ist es recht wichtig zu sehen, welcher »open()« schief geht, um der Umgebung dann die noch fehlende Datei zu geben. Die generierten Informationen berücksichtigen im Gegensatz zu Strace aber die erweiterten Sicherheitseigenschaften von HP-LX. Statt “Geht nicht” erklären sie dann “Geht nicht, weil”.

Das Audit-System wird mit einer XML-Datei konfiguriert, sie legt fest, wann welche Aufrufe protokolliert werden. Die Protokolle enthalten zu jedem Call weitere Eigenschaften wie die User-ID des aufrufenden Prozesses, den Returncode des Aufrufs und die Parent-ID des Prozesses. Diese Zusatzinformationen können als Parameter für einen Filter dienen, der etwa nur alle Open-Aufrufe von User-ID 25 ausgibt.

Zu guter Letzt lassen sich Compartments auch noch versiegeln. Das bedeutet, dass Prozesse in diesem Compartment die User-ID Null nicht mehr erlangen können, es gibt also keine Root-Rechte mehr. Set-UID-Root-Programme werden in einem versiegelten Compartment ohne Root-Rechte ausgeführt.

Abbildung 2: Changeroot erklärt ein beliebiges Verzeichnis (hier »/compt/web« und »/compt/mail«) zum neuen Root-Verzeichnis. Der Pfad »/compt/web/lib« wird von den betroffenen Prozessen dann als »/lib« gesehen.

Abbildung 3: Diese Verzeichnisse und Dateien erzeugt der Aufruf von »tlcompadd -r -i web« unterhalb des Verzeichnisses »/compt«. Damit ist »/compt/web« schon als Changeroot-Umgebung vorbereitet.

Webserver im Compartment

Nach der Theorie wird es Zeit für ein konkretes Beispiel: Hier eignet sich ein Webserver hervorragend. Mit Compartments ist nicht nur der Serverprozess selbst gut abzusichern, die Abschottung bezieht sich auch auf weitere Teile einer Web-Applikation wie CGI-Skripte oder ganze Application Server. Schließlich werden sich Web-Hosting-Unternehmen freuen, dass sie die Server verschiedener Kunden auf einem einzelnen Rechner aufsetzen können und die Kunden dennoch voneinander getrennt sind.

Wie funktioniert das nun unter HP-LX? Zuerst ist ein neues Compartment nötig, das mit dem Kommando »tlcompadd« angelegt wird. Der Name dieses Befehls leitet sich übrigens aus dem früheren Namen von HP-LX ab: Trusted Linux. Das Standardverzeichnis für Compartments ist »/compt«, und unter »/compt /web« soll eine Changeroot-Umgebung für den Apache liegen. Der Aufruf »tlcompadd -r -i web« teilt dem System mit, dass es das neue Compartment mit dem Namen »web« anlegen soll. Dazu erzeugt das Kommando das Verzeichnis »/compt/web«.

Die Option »-r« sorgt dafür, dass dieses Verzeichnis als Changeroot-Umgebung geeignet ist: Es enthält einige Shared Libraries, ein »/dev/null«-Device sowie rudimentäre »/bin«- und »/tmp«- Verzeichnisse (siehe Abbildung 3). Der Purist wird vielleicht wieder einige Bibliotheken löschen, da es mehr sind als unbedingt nötig.

Mit der Option »-i« erzeugt Tlcompadd ein Startup- und ein Shutdown-Skript, die es dann unterhalb von »/etc/tlinux /init« ablegt. Die Skripte starten und beenden das Compartment und die darin laufenden Prozesse. Sie sorgen außerdem für das Laden der Dateizugriffs- und IPC-Regeln.

Damit das Ganze auch funktioniert, muss im Startup- und im Shutdown-Skript der Compartment-Name richtig ausgefüllt sein. Standardmäßig gehen diese Skripte davon aus, dass es in der Changeroot-Umgebung die Skripte »/etc /rc.start« und »/etc/rc.stop« gibt. Aber dies kann auch durch eigene Aufrufe ersetzt werden.

web /compt/web/apache/logs read,write,append active
web /compt/web read active
web /usr/sbin read active
web /lib read active
web / none active

Zugang zu Dateien

Als Nächstes sind die Regeln für den Dateizugriff an der Reihe. Sie werden in der Datei »/etc/tlinux/fs/web« konfiguriert. Unser Webserver läuft unterhalb der Changeroot-Umgebung im Verzeichnis »apache«. Seine Logdateien sind die einzigen Dateien, auf die er Schreibrechte benötigt; sie befinden sich in »apache /logs«. Listing 1 zeigt, wie die Konfigurationsdatei dann aussehen muss.

Der eigentliche Prozess läuft in der Changeroot-Umgebung. Während des Starts ist das Compartment zwar bereits gesetzt, aber erst danach wird »/usr /sbin/chroot« aufgerufen. Daher sind die Pfade global und auch »/lib« und »/usr/sbin« müssen für das Compartment lesbar sein.

Im Verzeichnis »/etc« in der Changeroot-Umgebung fehlen noch die Dateien »passwd« mit Einträgen für Root und den Web-User (beide ohne gültiges Passwort), »group«, »nsswitch.conf« und eventuell »resolv.conf«. Die Datei »/etc /rc.start« in der Changeroot-Umgebung kann dann einfach den Eintrag »/apache /bin/apachectl start« enthalten, die »/etc/rc.stop« entsprechend »/apache/bin/apachectl stop«.

Nun lässt sich der Webserver mit »tlcompstart web« starten. Allerdings kann noch niemand auf ihn zugreifen, nur innerhalb des Web-Compartments sind Verbindungen möglich. Es fehlen also noch die IPC-Regeln, in diesem Beispiel genügen Internet-Sockets.

Geregelte Kommunikation

Diese Regeln liegen in der Datei »/etc /tlinux/rules/web«. Für TCP-Ports reicht eine Regel in Richtung des Verbindungsaufbaus, die Umkehrregeln fügt HP-LX dynamisch ein. Nur bei UDP, etwa für einen Nameserver, müssen die Regeln für die Antwortpakete explizit eingetragen werden. In unserem Beispiel reicht eine Regel (erste Zeile in Listing 2). Die zweite Regel erlaubt dann auch noch HTTPS-Verbindungen.

Die Regeln besagen, dass beliebige Hosts von außen mit dem Compartment »web« auf den Ports 80/TCP und 443/TCP Verbindungen aufbauen können. Bei Maschinen mit mehreren Netzwerkkarten würde allerdings nicht »NETDEV ANY«, sondern »NETDEV LAN-Interfacename« stehen. Es wäre das Interface einzutragen, das die Verbindungen entgegennehmen soll.

Etwas trickreicher ist es, wenn das Web-Compartment noch mit einem anderen Compartment auf der gleichen Maschine kommunizieren soll. In diesem Fall muss vor und hinter dem Pfeil jeweils ein Compartment stehen. »HOST localhost« funktioniert nicht. Die dritte Zeile in Listing 2 erlaubt es dem Web-Compartment, mit einer Postgres-Datenbank im Compartment »db« zu kommunizieren.

HOST * -> COMPARTMENT web PORT 80 METHOD TCP NETDEV ANY
HOST * -> COMPARTMENT web PORT 443 METHOD TCP NETDEV ANY
COMPARTMENT web -> COMPARTMENT db PORT 5432 METHOD TCP <H>Ó  NETDEV lan_lo

Erzieltes Ergebnis

Mit diesen Regeln ist der Webserver in seinem eigenen Compartment einsatzbereit. Sollte ein Angreifer durch einen Buffer-Overflow den Apache dazu bringen, eigenen Code auszuführen, wäre die einzige mögliche Aktion ein schreibender Zugriff auf das Apache-Logverzeichnis. Ist die Datenbank-Verbindung auch zugelassen, so wäre das ein weiterer Angriffspunkt. Ein Root-Kit würde nicht sehr weit führen, da es wieder im Web-Compartment eingesperrt wäre. Damit sieht es auch nur die »httpd«-Prozesse, auch an Netzwerkports (»netstat -an«) sind nur die zum Web-Compartment gehörenden Ports sichtbar. Verbindungen aus dem Compartment heraus sind nicht möglich.

Die Integration weiterer Applikationen in eigenen Compartments setzt voraus, dass der Integrator weiß, was die Applikation treibt. Die Fehlersuche kann viel Arbeit machen, es geht um Fragen wie: Wo ist doch noch Schreibzugriff notwendig, welche Netzwerkverbindung sind noch nötig und so weiter.

Die tägliche Arbeit

Wenn das System fertig installiert ist, gibt es nur zwei Wege, sich im voll privilegierten Modus einzuloggen. Voll privilegiert bedeutet hierbei, dass die Admin-Bits zur Compartment-Verwaltung und zum Compartment-Wechsel gesetzt sind, beide Aktionen also erlaubt sind. Die eine Möglichkeit ist die erste virtuelle Konsole. Der andere Weg ist ein SSH-Login als Benutzer »tlinuxadm«, für den bei der Installation (siehe Kasten “Installation von HP-LX”) der SSH-Key hinterlegt wurde. Sollte auf dem Client die kommerzielle SSH-Version laufen, muss der Public Key erst mittels »ssh-keygen« ins OpenSSH-Format umgewandelt werden.

Diese Admin-Bits sind nur an den (modifizierten) Init-Prozess vererbbar. Entsprechend werden der Login-Prozess auf der ersten virtuellen Konsole und der »sshd« aus der Inittab gestartet und erhalten dabei das Flag »t_respawn«. Der Ssh-Daemon kommuniziert dann mit einem speziellen PAM-Modul, das entscheidet, ob ein Benutzer die Bits erhält oder nicht.

Das PAM-Modul verfügt über eine eigene Konfigurationsdatei »/etc/tlinux /users/access«. Sie legt fest, in welchem Compartment ein Benutzer landet, wenn er sich auf dem System anmeldet, und ob er die Admin-Bits erhält. Steht der Benutzer nicht in dieser Datei, läuft die Shell des Benutzers im System-Compartment. Trotz des Namens handelt es sich hier um das unterste Compartment, von dort aus ist keinerlei IPC möglich.

Bewertung

Alles in allem macht HP-LX einen guten Eindruck. Im Vergleich zu anderen Systemen wie etwa LIDS [2] ist es vielleicht in der Standardinstallation nicht ganz so versiegelt, dafür aber im laufenden Betrieb einfacher zu administrieren. Sollte Sicherheit vor Administrierbarkeit gehen, so kann man auch dem Ssh-Server in der Inittab das Flag »t_respawn« wegnehmen. Damit wäre kein voll privilegierter Zugriff über das Netzwerk mehr möglich.

Die Stufe des Schutzes ist mit LIDS vergleichbar. Bei LIDS gibt es jedoch keine Compartments, die aufgestellten Regeln gelten dort für die Binaries. Die Regeln sind an den Inode der Programmdateien gekoppelt und gelten daher für das ganze System. Bei HP-LX sind die Prozesse innerhalb ihres Compartments genauso eingeschränkt, wie es die Prozesse bei LIDS auf dem ganzen System sind. Wenn die Regeln sinnvoll definiert wurden, kann ein Eindringling in beiden Fällen nur noch sehr begrenzten Schaden anrichten. (fjl)