Kritische Betrachtung von AppArmor

Wenn Sie bereits bis hierher gelesen haben, kennen Sie AppArmor bereits recht gut. Falls Sie direkt hierhin geblättert haben, werden Sie vielleicht einige Begriffe nachschlagen müssen. Dennoch sollten Sie in der Lage sein, die folgenden Ausführungen zu verstehen. AppArmor erhöht sicherlich die Sicherheit des Systems, auf dem es installiert wurde. Als Mandatory-Access-Control-System (MAC) muss es sich aber auch den Vergleich mit anderen ähnlichen Lösungen gefallen lassen. Alternative Lösungen sind:

• SELinux
• LIDS (http://www.lids.org)
• grsecurity (http://www.grsecurity.org)
• RSBAC (http://www.rsbac.org)
• etc.

Ich werde hier lediglich AppArmor betrachten. Eine Betrachtung von SELinux erfolgt in dem entsprechenden Kapitel.

Bei der Betrachtung von AppArmor fällt als erstes die leichte Handhabung, die verständliche Syntax der Profil-Dateien und die gute Dokumentation auf. Dies sind alles Pluspunkte für AppArmor.

Aus Sicht der Sicherheit ist es jedoch bei AppArmor ungünstig, dass das System in vertrauenswürdige und nicht vertrauenswürdige Programme unterschieden werden muss. Die vertrauenswürdigen Programme werden von AppArmor nicht überwacht und dürfen auf dem System jede, durch die UNIX-Rechte erlaubte, Tätigkeit durchführen. Lediglich die nicht vertrauenswürdigen Applikationen werden von AppArmor zusätzlich überwacht.

Ein zweiter Kritikpunkt ist die Tatsache, dass AppArmor als Zugriffsattribut den Dateinamen verwendet. Ein Umbenennen oder Kopieren der Datei entzieht eine Datei oder Applikation der Überwachung von AppArmor. Änderungen der Installationsorte von Applikationen durch den Programmierer führen dazu, dass die Applikation plötzlich nicht mehr überwacht wird. Außerdem können nicht alle Objekte unter Linux über einen Dateinamen angesprochen werden. Netzwerkverbindungen, Prozesse und IPC-Aufrufe können nicht über Dateinamen angesprochen und daher nicht von AppArmor überwacht werden.

AppArmor kann nicht zwischen unterschiedlichen Benutzern unterscheiden. Applikationen, die auf Benutzerdaten zugreifen müssen, benötigen immer den Zugriff auf die Daten sämtlicher Benutzer. Dies löst AppArmor über die Variable @HOME und stellt dem Befehl den Zugriff auf alle Heimatverzeichnisse zur Verfügung.

Schließlich bleibt noch die Qualität der von Novell mitgelieferten Profile zu betrachten. Zunächst enttäuscht die Menge der mitgelieferten Profile. Novell unterstützt in der aktuellen Version 10.1 mit allen Updates nur Profile für die folgenden Applikationen:

• /bin/netstat
• /bin/ping
• /lib/ld-2.2.so
• /sbin/klogd
• /sbin/syslogd
• /usr/bin/ldd
• /usr/sbin/identd
• /usr/sbin/mdnsd
• /usr/sbin/nscd
• /usr/sbin/ntpd
• /usr/sbin/traceroute

Alle weiteren Profile in dem Verzeichnis /etc/apparmor/profiles/extra gelten als nicht unterstützt. Ein Anwender, der diese Profile nutzen möchte, tut auch gut daran, diese zunächst zu analysieren und zu testen, denn leider enthalten diese Profile teilweise fehlerhafte Pfade oder logische Fehler.

So verweist das Profil etc.cron.daily.tmpwatch auf einen Cronjob tmpwatch den es auf dieser Version nicht gibt. In dem Profil usr.lib.RealPlayer10.realplay wird auf die Applikation /opt/MozillaFirefox/lib/firefox-bin verwiesen, die bei SuSE 10.1 unter /usr/lib/firefox/firefox-bin installiert wurde. Ähnlich hartcodierte Pfade befinden sich in dem Profil des Acrobat Readers. Ein Upgrade der Java-Virtual-Machine macht das Profil unbrauchbar.

Schließlich kann AppArmor den Informationsfluss nicht überwachen. Wenn eine Applikation eine Datei schreibt, kann AppArmor nicht einschränken, welche andere Applikation diese Datei wieder lesen darf, da der verwendete Dateiname beliebig ist und daher nicht von AppArmor als Attribut genutzt werden kann. Dies ist speziell problematisch bei Dateien in Verzeichnissen wie /tmp. Hier muss der Administrator den klassischen UNIX-Dateirechten (DAC) vertrauen. AppArmor bietet hier keinen zusätzlichen Schutz.