Grundsätzlich unterscheidet SELinux zwischen geschützen (confined) und ungeschützen (unconfined) Prozessen. Erstere laufen in einer eigenen SELinux-Domäne, beispielsweise
»httpd_t
«
. Alle anderen Prozesse befinden sich in der so genannten
»unconfined_t
«
-Domäne. Für Prozesse in dieser Domäne existieren keine Einschränkungen hinsichtlich der SELinux-Implementierung Type Enforcement. Das heißt, ein Zugriff ist auf sämtliche Ressourcen möglich. Trotzdem funktionieren manche Applikationen, die in der Unconfined-Domäne laufen, nicht korrekt. Das Audit-Log zeigt dann einen Eintrag wie in
Listing 7
.
Listing 7
Unconfined-Fehler
01 audit(1234106860.110:0): avc: denied { execmod } for pid=4094 02 comm=firefox-bin path=/home/tscherf/.mozilla/plugins/libflashplayer.so 03 dev=hda9 ino=1056003 scontext=user_u:system_r:unconfined_t 04 tcontext=user_u:object_r:default_t tclass=file
Doch wie kann so ein Fehler überhaupt für eine Anwendung in der Unconfined-Domäne auftreten? Schließlich gibt es für Prozesse in dieser Domäne ja fast keine Einschränkungen. Die Antwort ist ganz einfach. Mit Fedora Core 5 wurden erstmals diverse Memory-Checks eingeführt. Sie prüfen auf ein merkwürdiges Verhalten einer Applikation bezüglich ihrer Speichernutzung. Diese Tests gelten für sämtliche Prozesse, unabhängig davon, in welcher SELinux-Domäne diese gerade ablaufen.
Der Grund hierfür liegt einfach darin, dass böswillige Angreifer Kontrolle über ein System erhalten, indem sie durch das Ausnutzen einer Sicherheitslücke beliebigen Programmcode auf der betroffenen Maschine ausführen können. Hierfür kommen beispielsweise Buffer-Overflow-Attacken zum Einsatz.
Diese versuchen bestimmte Speicherbereiche mit eigenem Programmcode (Shellcode) zu überschreiben. Wenn der betroffene Speicherbereich einer Applikation nun nicht nur beschreibbar, sondern auch ausführbar ist, kann ein Angreifer den eingeschleusten Programmcode ausführen und so zum Beispiel eine Shell auf dem System starten. Läuft die Anwendung dann noch unter dem Benutzerkontext Root, ist keine weitere Arbeit mehr notwendig, der Angreifer hat sein Ziel erreicht und die Kontrolle über das System erlangt.
Um dies zu verhindern, überprüfen einige Tests das Speicherverhalten von Applikationen. Diese Tests lassen sich systemweit über Booleans aktivieren oder deaktivieren. Die entsprechenden Default-Einstellungen sehen auf einem Fedora-System so aus:
# getsebool -a | grep allow_exec allow_execheap --> off allow_execmem --> on allow_execmod --> off allow_execstack --> on
Gerade beim Einsatz von Shared Libraries tritt immer wieder der Fehler auf, dass diese eine Text-Relocation durchführen möchten. Hierbei markiert eine Anwendung einen bestimmten Speicherbereich als read/write, kopiert den gewünschten Programmcode an diese Speicherstelle und ändert die Rechte des Speicherbereichs anschließend wieder auf read/exec. Solch eine Vorgehensweise ist meist nicht notwendig und lässt sich durch den Einsatz anderer Programmiertechniken verhindern. Red-Hat-Entwickler Ulrich Drepper hat hierzu einen ausführlichen Blogeintrag verfasst [3] .
Da das Boolean für diesen speziellen Memory-Check standardmäßig aktiv ist, funktioniert die Anwendung natürlich nicht wie gewohnt. Häufig schieben Anwender das Problem dann auf SELinux, obwohl der Fehler tatsächlich im schlechten Programmcode der Anwendung liegt. Tritt ein solcher Fehler auf, sollte der Benutzer einen entsprechenden Bug-Report an den Hersteller senden. Wer der Applikation vertraut und nicht auf einen Fix warten will, kann das Boolean, das für den genannten Memory-Check zuständig ist, mit folgendem Befehl deaktivieren:
setsebool -P allow_execmod=1
Damit erhält jedoch jede Applikation das Recht, Text-Relocations durchzuführen. Besser ist es, nur der ausgewählten Anwendung das notwendige Recht zu gewähren. Da dieser Fehler recht häufig vorkommt, haben die SELinux-Entwickler sogar einen eigenen SELinux-Typ für solch fehlerhafte Programme entwickelt:
»textrel_shlib_t
«
. Damit erhält die SELinux-Policy den entsprechenden Eintrag für das fehlerhafte Programm:
semanage fcontext -a -t textrel_shlib_t /home/tscherf/.mozilla/plugins/libflashplayer.so restorecon -v /home/tscherf/.mozilla/plugins/libflashplayer.so
Ein solcher Zugriff sollte aber nur in Ausnahmefällen erlaubt sein. Die Anwendung bekommt so Rechte zugesprochen, die sie eigentlich nicht braucht. Damit wächst nur das Sicherheitsrisiko, das SELinux ja eigentlich verringern soll.
Statt auf den zusätzlichen Schutz durch SELinux zu verzichten, sollte der verantwortliche Admin sich die Zeit nehmen, das notwendige Know-how zu erwerben, um mögliche Probleme selbst zu lösen. Zur Fehlersuche sind die Logs des Audit-Daemon unverzichtbar. Um diese zentral zu verwalten, bietet sich im Unternehmenseinsatz ein grafisches Frontend wie Prewikka an. Mit dem passenden Plugin
»audispd-prelude
«
schicken dann sämtliche Systeme ihre Audit-Meldungen an das Prewikka-System. Über ein komfortables Webinterface lassen sich diese dann verfolgen. Mögliche Fehlerquellen sind damit leicht identifizierbar und mit den hier vorgestellten Techniken schnell behoben.
Infos