Einführung

Ist Sicherheit wichtig? Was ist Sicherheit? Wie erreicht man Sicherheit? Es gibt zahllose Bücher, auch von mir, rund um das Thema Sicherheit. Ich habe mich bisher vor allem mit der adminstrativen Sicherheit beschäftigt: Wie konfiguriert man ein VPN oder eine Firewall? Eine korrekte Administration der Systeme genügt jedoch nicht. Selbst wenn der Administrator alles richtig macht, benutzt er doch Software, die Fehler enthält. Jede Software enthält Fehler. Viele wurden noch nicht gefunden. Einige dieser Fehler erlauben es einem Angreifer, die Gewalt über die Software zu übernehmen und diese fernzusteuern. Da die typischen Programmierfehler (Buffer-Overflows, Formatstring-Schwachstellen, etc) seit Jahren bekannt sind und keine Besserung auf der Seite der Programmierer zu erwarten ist, sollte jeder Administrator mit derartigen Angriffen rechnen. Auch hier gibt es reichlich Literatur, die sich mit der Problematik beschäftigt. Wie zum Beispiel erkennt man einen Einbrecher?

Dabei könnte die Lösung relativ einfach sein. Das Betriebssystem dürfte den Angriff einfach nicht erlauben. Natürlich können die Betriebssysteme nicht die Programmierfehler verhindern. Aber sie sollten es dem Angreifer erschweren, nach Erkennung und Ausnützung des Programmierfehlers, die Hoheit über das System zu übernehmen. Weist der mount Befehl eine Sicherheitslücke auf, so müsste das Betriebssystem einen Angreifer daran hindern, dass er mit dem Prozess einen zusätzlichen Benutzer anlegt. Ein Apache Prozess müsste daran gehindert werden, zusätzliche Hackertools aus dem Internet nachzuladen.

Aktuelle Betriebssysteme können dies nicht verhindern, da sie alle ein Discretionary-Access-Control System (DAC) verwenden. Diese Systeme werten im wesentlichen lediglich Identitäten der Benutzer aus. Jedes Objekt auf dem System gehört einem Benutzer. Dieser Benutzer darf entscheiden, wer auf das Objekt zugreifen darf und setzt entsprechende Rechte. Möchte derselbe Benutzer oder ein anderer Benutzer zugreifen, prüft das Betriebssystem, ob dieser Zugriff erlaubt ist. Im Angriffsfall greift der Angreifer nicht direkt zu, sondern verwendet hierzu bestimmte Software. Diese Software hat meistens eine einfache, sinnvolle und harmlose Funktion und verfügt über mehr Rechte, als dem Angreifer direkt zur Verfügung stehen. Es handelt sich um SetUID-Programme, die im Kontext eines anderen Benutzers (z.B. root) ausgeführt werden, oder um Netzwerkdienste, die dem Angreifer Zugriff auf das System gewähren. Diese Software kann Fehler wie Bufferoverflows oder Formatstringschwächen aufweisen, von Viren befallen oder mit einem Trojaner versehen sein. Dann kann der Angreifer das Verhalten des Prozesses verändern und an Stelle der harmlosen Funktion die Ausführung bestimmen. Ein DAC-System wird diesem Prozess ensprechend seiner Identität alle Funktionen erlauben. Der Angriff kann von einem DAC-System nicht erkannt und unterbunden werden.

Am deutlichsten wird das vielleicht an einem Beispiel: Unter Linux verfügt das Kommando ping über das SetUID-Recht. Das bedeutet, dass der Prozess mit der effektiven UID des Benutzers root arbeitet. Der Befehl kann also einen Benutzer erzeugen oder den Rechner rebooten, da das Kommando über das Recht verfügt mit root-Privilegien zu arbeiten:

[root@supergrobi ~]# ls -l /bin/ping
-rwsr-xr-x 1 root root 36608 24. Feb 16:42 /bin/ping

Findet ein unprivilegierter Benutzer einen Fehler in dem Befehl ping, der es ihm erlaubt die Hoheit über den Prozess zu erlangen, kann er beliebige privilegierte Funktionen nutzen. Das DAC-System erkennt, dass der Prozess mit den Rechten des Benutzers root arbeitet und erlaubt dem Prozess jeglichen Zugriff.

Schutz bietet hier nur ein Mandatory-Access-Control System (MAC), welches nicht die Identitäten der Prozesse und Objekte auswertet, sondern zusätzliche Attribute unabhängig von den Identitäten nutzt, um über einen Zugriff zu entscheiden. Unter der Kontrolle des MAC können die Privilegien von den betroffenen Benutzern und Prozessen dann nicht geändert werden.

Sowohl AppArmor als auch SELinux bieten hierfür Möglichkeiten. Jedoch sind die beiden Ansätze vollkommen unterschiedlich. Während AppArmor dies ohne großen Aufwand erreicht und damit leicht zu erlernen ist, krempelt SELinux alles um, was Sie über Vergabe von Rechten unter Linux wissen. Damit ist es aber auch im Gegensatz zu AppArmor möglich, den Zugriff auf Ports, IP-Adressen, entfernte Rechner, IPsec-Verbindungen und sogar einzelne Pakete zu kontrollieren.

Welches System Sie wählen, überlasse ich Ihnen und Ihrer Einschätzung der Bedrohung. Sicherlich wird die Wahl durch die von Ihnen bevorzugte Distribution mit beeinflusst. Wünschen Sie kommerziellen Support, so stehen im Moment nur die Distributionen SUSE Linux Enterprise Server (SLES) mit AppArmor und Red Hat Enterprise Linux (RHEL) mit SELinux zur Wahl.

Falls Sie sich noch fragen, ob Sie tatsächlich ein MAC-System einsetzen möchten oder ob Sie sich hiermit möglicherweise eine zusätzliche Sicherheitslücke erzeugen, sollten Sie immer daran denken, dass sowohl SELinux als auch AppArmor nur zusätzlich den Zugriff prüfen. Die klassische Zugriffskontrolle über die Identitäten und die Dateirechte erfolgt weiterhin. Es genügt nicht, dass SELinux oder AppArmor Ihnen Schreibrechte an einer Datei zuweisen, wenn Sie nicht das Recht w an der Datei selbst haben.