Capsicum – Mehr Sicherheit für FreeBSD

Administratoren treibt es in schöner Regelmäßigkeit den Schweiß auf die Stirn, wenn in Security Bulletins wieder einmal erläutert wird, dass Schadcode für die verwendeten Programme kursiert. Betroffen sind Webbrowser, E-Mail-Programme, Archivierungstools und sogar Office-Pakete. Es ist nicht (nur) die Nachlässigkeit bei der Verwendung von Bibliotheken, die es Eindringlingen erleichtert, Schadcode auszuführen, sondern auch der gezielte Angriff auf fehlerhafte Anwendungen. Mit den unter FreeBSD bekannten Mechanismen wie Chroot oder Jails ist dem nur schwer beizukommen.

Abhilfe schafft das Einsperren von Anwendungen in eine Sandbox, eine Umgebung, die nur extrem limitierte Resourcen bereitstellt. Da FreeBSD bis zur Version 8 einen solchen Mechanismus nicht vorsieht, wurde mit FreeBSD 9 die Umgebung Capsicum (lateinisch für Chili) geschaffen. Sie bietet neben einer geschützten Umgebung (Sandbox), aus der eine Anwendungen nicht ausbrechen kann, auch die Möglichkeit der fein granulierten Rechtevergabe.

Klassische Rechte

Traditionell besitzt FreeBSD wie Linux und andere Unix-Systeme ein sehr simples Rechtesystem. Der Grund dafür ist in der Geschichte der Unix-Systeme zu suchen, die ursprünglich nicht für einen im weltweiten Internet vernetzten Desktop konzipiert waren. Daraus entstanden hauptsächlich zwei Mechanismen der Zugriffskontrolle. Zum einen gibt es die Discretionary Access Control (DAC, diskrete Zugriffskontrolle), die von der Benutzerkennung abhängt. Hierbei wird die Entscheidung, ob auf eine Ressource zugegriffen werden darf, allein auf der Basis der Kennung des Users getroffen. Das bedeutet, die Zugriffsrechte für Daten werden für jeden Benutzer von einem Administrator oder vom Benutzer selbst festgelegt. Bestes Beispiel hierfür ist ein Home Directory, auf das nur der Benutzer Zugriff hat, der es auch besitzt.

Der Nachteil der Methode zeigt sich am Kommando »passwd« zum Ändern des Benutzerpassworts. Damit jeder User selbst sein Passwort in die Benutzerdatenbank eintragen und ändern kann, muss das »passwd« -Kommando in die Datei »/etc/passwd« schreiben dürfen. Es hat aber nur der User Root die Berechtigung, sie zu verändern. Vereinfacht dargestellt bedient man sich eines Tricks und setzt für den Befehl »passwd« das SUID-Flag und das Kommando wird mit Root-Rechten ausgeführt und die Änderung an »/etc/passwd« wird durchgeführt. Unter Umständen ist dieser Mechanismus das Einfallstor für Schad-Software.

MAC-Security

Der andere Mechanismus zur Zugriffskontrolle ist die Mandatory Access Control (MAC, zwingend erforderliche Zugangskontrolle). Hierbei wird im Gegensatz zur DAC die Zugriffsberechtigung auf Basis eines Regelwerks erteilt. Der Nachteil dieser Methode ist aber, dass ein solches Regelwerk innerhalb der Anwendung definiert werden muss, was einen erhöhten Programmieraufwand zur Folge hat. Außerdem trägt der Programmierer die volle Verantwortung für die Vergabe der Berechtigungen.

Die beiden Arten der Zugriffskontrolle wurden in erster Linie dafür entwickelt, unerlaubten Zugriff auf Dateien zu reglementieren. Der Zugriff auf Speicherbereiche oder gar Kontrollstrukturen eines Kernels werden damit nicht unterbunden. Auch wurden die Mechanismen nie dafür entwickelt, moderne Desktop-Anwendungen wie Webbrowser oder Office-Pakete abzusichern.

Das ist eine kritische Angelegenheit, wenn man bedenkt, dass sie aus dubiosen Quellen stammende Information verarbeiten und darstellen. Mit DAC oder MAC lässt sich die Ausführung von Schadcode eines Javascripts oder Makro-Viruses nur schwer verhindern.

Der FreeBSD-Kenner wird an dieser Stelle einwerfen, dass es Jails gibt, mit denen man ebenfalls die Möglichkeit hat, eine Sandbox aufzubauen. Das ist korrekt, aber der Administrationsaufwand und Ressourcen-Verbrauch sind doch enorm, wenn man für jede Anwendung eine Jail erstellt. Außerdem löst es nicht das Problem, dass Schadcode ein System infiltriert.