Tritt ein Fehler in der SE-Linux-Konfiguration eines Servers auf, fehlt vielen Admins einfach die Zeit, dem eigentlichen Problem auf den Grund zu gehen. Kurzerhand lassen sie die Maschine ohne aktivierten SE-Linux-Schutz weiterlaufen und verschieben die Problemlösung auf später. Dieser Artikel zeigt, dass es auch anders geht: Mit dem nötigen Know-How und einigen kleinen Tricks läuft jede Anwendung auch mit aktiviertem Schutzschild.

Kurzer Rückblick

Bei SE Linux handelt es sich um ein sehr flexibles Security-Framework auf Basis der Mandatory-Access-Control, das auf dem Flask-Forschungsprojekt der amerikanischen NSA-Behörde basiert [1]. Im Standard-Kernel ist es über die sogenannte Linux-Security-Module API (LSM) integriert. Alle Interaktionen zwischen so genannten Subjekten und Objekten sind durch eine gesonderte Security-Policy zu autorisieren. Die Anweisungen enthalten dabei jedoch keine Datei-, Prozess- oder Benutzernamen, stattdessen kommt ein abstrahiertes Model mit Security-Labeln zum Einsatz. Prozesse und Benutzer bekommen diese dynamisch zugewiesen, Dateien speichern das Label in den erweiterten Attributen. Es ist möglich, diese Policy zur Laufzeit des Systems zu ändern. Hierbei findet jedoch eine strikte Trennung von Policy und deren Durchsetzung statt. Für dieses Enforcement sind diverse Hooks im Linux-Kernel verantwortlich. Sie erweitern die klassischen Zugriffsrechte der Discretionary-Access-Control (DAC) um eine entsprechende MAC-Funktionalität. Über eine binäre Policy-Datei gelangen die eigentlichen Regelwerke in den Security-Server des Linux-Kernels.

SE Linux kennt drei Modi: Im Enforcing-Mode ist jeder einzelne Zugriff einer Kontrolle durch die SE-Linux-Policy ausgesetzt. Jeder Zugriff wird ausgewertet und gegebenfalls untersagt wenn es keine Regel gibt, die diesen Zugriff erlaubt. Im Permissive-Mode wird ebenfalls jeder Zugriff überwacht, allerdings kommt es nicht zur Durchsetzung der Regeln. Das bedeutet, dass ein Zugriff selbst dann stattfindet, wenn keine Regel den Zugriff explizit erlaubt. SE Linux schreibt für jeden nicht durch eine Regel erlaubten Zugriff einen Logeintrag, allerdings nur für beim ersten Mal. Alle weiteren Zugriffe unterdrückt das System stillschweigend. Im Disabled-Mode ist SE Linux überhaupt nicht aktiv. Es kommen lediglich Zugriffsentscheidungen auf Basis der DAC zum Einsatz. Dabei muss der Administrator daran denken, dass Dateien, die im Disabled-Mode erzeugt wurden, auch kein Security-Label bekommen.

Zur Erweiterung des klassischen Discretionary-Access-Control-Modells stellt SE Linux verschiedene Implementierungen zur Verfügung:

• Type-Enforcement (TE)
• Role-based-Access-Control (RBAC)
• Multi-level-Security (MLS)
• Multi-Category-Security (MCS)

Die wichtigste Implementierung ist hierbei das Type-Enforcement. Es regelt den Zugriff von einem Subjekt, beispielsweise einem Prozess, auf die diversen Objekte, beispielsweise Dateien oder Verzeichnisse. Allerdings gibt es eine Vielzahl unterschiedlicher Objekte. Zu ihnen diesen zählen neben Dateien und Verzeichnissen beispielsweise auch Netzwerk-Ports. Die den Subjekten und Objekten zugewiesenen Security-Label sind auch unter dem Namen Domäne oder Typ bekannt. Allgemein ausgedrückt regelt das Type-Enforcement, welche Domäne auf welchen Typen zugreifen darf.

Genau hier liegt oft das Problem. Besitzt ein Objekt nicht den richtigen Typ, ist der Zugriff hierauf nicht möglich wenn das System sich im SE-Linux Enforcing-Mode befindet. Ein Log-Eintrag in der Datei »/var/log/audit/audit.log« sieht dann zum Beispiel wie in Listing 1 aus.

type=AVC msg=audit(1217917079.027:14267): avc:  denied  { getattr } for
pid=10054 comm="httpd" path="/var/www/html/index.html" dev=dm-2 ino=1974309
scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0
tclass=file

Der Log-Typ bestimmt hierbei den Ursprung der Nachricht. AVC steht für Access-Vector-Cache und ist ein Teil des Security-Servers im Kernel, der Zugriffsvektoren zwischenspeichert. Der Log-Typ »SYSCALL« und bezieht sich beispielsweise auf Events, die das Audit-Subsystem festhält, wenn es um das Monitoring von System-Calls geht. Mit Hilfe von »ausearch -m Typ« ist ein Zugriff auf einen ganzen bestimmten Log-Typen möglich. Der nächste Eintrag gibt den Zeitpunkt des Events in Unix-Zeit an. Mit Hilfe von »date -d @Unix-Zeit« lässt sich diese leicht in ein menschenlesbares Format verwandeln. Im Anschluss erfolgt die genaue Art der Log-Meldung, also ob es sich um eine Deny-Meldung handelt oder nur um eine Information, beispielsweise ob die SE-Linux-Policy neu geladen wurde oder ob sich der SE-Linux-Mode geändert hat.

Die nächsten beiden Angaben (»pid« und »comm« ) bestimmen die Herkunft der Fehlermeldung, hier also einen Webserver-Prozess mit seiner Prozessnummer. Das Objekt der Begierde folgt unmittelbar in Form eines Dateipfads (»path« ), Device (»dev« ) und Inode-Nummer (»ino« ). Da für die Interaktion zwischen Prozess und Datei jedoch die Security-Label die größte Bedeutung haben, sind diese natürlich ebenfalls aufgeführt. »scontext« steht hierbei für den Source-Context des Webservers, »tcontext« für den Target-Context der Datei. Zum Abschluss gibt die Logmeldung noch Auskunft über den genauen Objekt-Typen. Hiermit ist die Unterscheidung von Objekten mit gleichem Security-Label möglich.

Seit einiger Zeit existiert für diese doch recht kryptischen Logeinträge eine Alternative. Fedora Core hat mit Version 6 den Setroubleshoot-Daemon [2] eingeführt. Bei dieser Gnome-Anwendung handelt es sich um ein plugin-basiertes Tool mit einer Vielzahl unterschiedlicher Regelsätze, die abhängig vom stattgefundenen Event dem Benutzer mit Rat und Tat zur Seite steht. Auch lassen sich unterschiedliche Benachrichtiguns- Mechanismen einstellen. Beispielsweise kann der Benutzer veranlassen, dass er eine Mail erhält, wenn das SE-Linux-System eine nicht erlaubte Aktion unterbindet. Benutzer mit einem grafischen Desktop haben die Möglichkeit, ein Sealert-Applet in Ihre Taskbar einzubinden um sich direkt über ein Pop-Up über aktuelle Meldungen des Setroubleshoot-Daemons zu informieren. Die Logeinträge der Anwendung finden sich in der Datei »/var/log/messages« (Listing 2).

Abbildung 1: Der grafische SE-Linux-AVC-Browser liefert Hilfestellung zu möglichen Problemen.

Aug  5 08:18:07 tiffy setroubleshoot: SELinux is preventing the httpd from
using potentially mislabeled files (/var/www/html/index.html). For complete
SELinux messages. run sealert -l 774df3c6-badf-4f42-b1f3-e8ff94897d6b

Folgt der Benutzer dem Rat des Setroubleshoot-Daemons und ruft den Befehl »sealert« mit den angegebenen Parameter auf, so erhält er eine detailierte Übersicht über das aufgetretene Problem und Informationen darüber, wie er das Problem beheben kann (Listing 3).

[root@tiffy ~]# sealert -l 774df3c6-badf-4f42-b1f3-e8ff94897d6b
Summary:
SELinux is preventing the httpd from using potentially mislabeled files
(/var/www/html/index.html).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]
SELinux has denied httpd access to potentially mislabeled file(s)
(/var/www/html/index.html). This means that SELinux will not allow httpd to
use these files. It is common for users to edit files in their home directory
or tmp directories and then move (mv) them to system directories. The problem
is that the files end up with the wrong file context which confined applications
are not allowed to access.
Allowing Access:
If you want httpd to access this files, you need to relabel them using
restorecon -v '/var/www/html/index.html'. You might want to relabel the entire
directory using restorecon -R -v '/var/www/html'.
Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                unconfined_u:object_r:user_tmp_t:s0
Target Objects                /var/www/html/index.html [ file ]
Source                        httpd
Source Path                   /usr/sbin/httpd
Port                          <Unknown>
Host                          tiffy.tuxgeek.de
Source RPM Packages           httpd-2.2.8-3
Target RPM Packages
Policy RPM                    selinux-policy-3.3.1-79.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   home_tmp_bad_labels
Host Name                     tiffy.tuxgeek.de
Platform                      Linux tiffy.tuxgeek.de 2.6.25.9-76.fc9.i686 #1
SMP
                              Fri Jun 27 16:14:35 EDT 2008 i686 i686
Alert Count                   1
First Seen                    Tue Aug  5 08:17:59 2008
Last Seen                     Tue Aug  5 08:17:59 2008
Local ID                      774df3c6-badf-4f42-b1f3-e8ff94897d6b
Line Numbers

Diese Meldung weist schon auf das eigentliche Problem hin. Die Datei »/var/www/html/index.html« besitzt das falsche Security-Label und somit ist ein Zugriff des Webservers hierauf nicht möglich. Eine mögliche Lösung ist ebenfalls aufgeführt:

# restorecon -R -v /var/www/html
# ls -ldZ /var/www/html
drwxr-xr-x. root root system_u:object_r:↩
httpd_sys_content_t:s0 /var/www/html

Der Aufruf von restorecon sorgt dafür, dass jedes Objekt im Verzeichnis »/var/www/html« das richtige Label bekommt. Danach sollte der Zugriff wieder funktionieren. Aber was ist in diesem Zusammenhang eigentlich das richtige Label? Es bezieht sich darauf, welches Label diese Datei in der binären Policy besitzt. Mit Hilfe von »semanage« bekommt der Admin schon im Vorfeld raus, wie das hinterlegte Label lautet:

# semanage fcontext -l | grep /var/www
/var/www(/.*)?          all files ↩
 system_u:object_r:httpd_sys_content_t:s0

Was soll man aber machen, um den Zugriff auf ein Objekt zu erlauben, das noch über keinen Eintrag in der Policy verfügt? In einem solchen Fall ist die Datei mit dem gewünschten Label in die Policy aufzunehmen. Dies funktioniert ebenfalls mit dem Tool »semanage« . Angenommen das Webserver-Documentroot befindet sich unterhalb von »/www« , so ist natürlich auch dieses Verzeichnis, mit allen darin enthaltenen Dateien, mit dem Label »httpd_sys_content_t« zu versehen. Der folgende Aufruf fügt der Policy einen entsprechenden Eintrag hinzu:

# semanage fcontext --add --type public_↩
content_rw_t '/www(/.*)?'
# restorecon -Rv /www

Der abschließende Aufruf von »restorecon« setzt das neue Label auf dem Verzeichnis und allen darin enthaltenen Dateien.

Genauso wie der Zugriff auf Dateien oder Verzeichnisse anhand eines Security-Label stattfindet, geschieht es auch mit Netzwerk-Ports. Das Tool »semanage« bindet das Security-Label an einen Port:

semanage port -a -t http_port_t -p tcp 8000

Hier wird der TCP-Port 8000 mit dem Label »httpd_port_t« versehen. Verifizieren lässt sich dies mit dem erneuten Aufruf von »semanage« :

# semanage port -l |grep http_port_t http_↩
port_t
tcp      80, 443, 488, 8000, 8008, 8009

Log aktivieren

Manchmal funktioniert eine Anwendung im Enforcing-Mode nicht, die Logdatei zeigt jedoch keine Fehlermeldung an. Wie kann das sein? Die Antwort ist ganz einfach. In der Policy exitsieren so genannte Dontaudit-Regeln, die einen Zugriff unterbinden, ihn aber nicht loggen. Das ist meistens ganz praktisch, wenn zum Beispiel eine Anwendung Aktionen durchführen will, die für eine korrekte Funktion aber nicht notwendig sind. Da SE Linux nach dem "Principle of least Privilege" arbeitet, sind solche Zugriffe nicht erlaubt. Natürlich soll aber auch nicht jedes Mal ein Eintrag im Log erfolgen.

Nun ist dieses Verhalten aber gerade bei der Suche nach einem Fehler nicht wünschenswert. Bestes Beispiel hierfür ist ein Problem im aktuellen SE-Linux-Paket von Red Hat Enterprise Linux (RHEL5) in Kombination mit einem installierten Postfix-Server. Hier greift ein Prozess aus der SE-Linux-Domäne »postfix_postdrop_t« auf eine Socket-Datei vom SE-Linux-Typ »sendmail_t« zu. Doch dieser Zugriff ist verboten. Die folgende Regel in der Policy verhindert jedoch auch einen entsprechenden Logeintrag:

dontaudit postfix_postdrop_t sendmail_t:unix_↩
stream_socket { getattr read write ioctl };

Mit einem kleinen Trick ist es jedoch möglich, sämtliche Dontaudit-Anweisungen aus der Policy zu entfernen. Das Tool Semodule ist hier des Rätsels Lösung:

semodule -DB

Anschließend finden sich alle AVC-Deny-Meldungen im Log wieder. Mit Hilfe dieser Meldungen ist es dann nicht schwer den Fehler zu beseitigen. Hierfür reicht es, ein neues Policy-Modul zu generieren, das den gewünschten Zugriff erlaubt. Das Policy-Modul mit allen notwendigen Anweisungen lässt sich mit dem Tool »audit2allow« erzeugen. Leitet der Anwender die Ausgabe der Logdatei »/var/log/audit/audit.log« durch dieses Tool, erhält er die notwendigen Regeln, um den Zugriff von »postfix_postdrop_t« auf »sendmail_t« zu gestatten (Listing 4).

# cat /var/log/audit/audit.log|audit2allow -l -R
gen_require(`
 type sendmail_t;
 type postfix_postdrop_t;
')
#============= postfix_postdrop_t ==============
allow postfix_postdrop_t sendmail_t:unix_stream_socket { getattr read write ioctl };

Speichert er die Ausgabe in einer Datei »mypostfix.te« , kann er im Anschluss aus dieser Datei das neue Policy-Modul bauen und dem Regelwerk hinzufügen:

make -f /usr/share/selinux/devel/Makefile
semodule -i mypostfix.pp

Damit jedoch nicht unnötig viele Meldungen in der Logdatei auftauchen und der Setroubleshoot-Dameon nicht plötzlich mit Logeinträgen überflutet wird, sollte man nach der Fehlersuche, der Policy die eben entfernten Dontaudit-Anweisungen mit dem Befehle »semodule -B« wieder hinzufügen.