High Availability lässt sich heute mit günstiger Hardware und einer großen Auswahl an kommerzieller sowie freier Software realisieren. ADMIN erklärt die ... (mehr)

Memory-Checks

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.

Fazit

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.

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

Infos

  1. NSA-SELinux-Projektseite: http://www.nsa.gov/research/selinux/
  2. Setroubleshoot-Tool des Fedora-Projekts: http://fedorahosted.org/setroubleshoot/
  3. Ulrich Drepper über SELinux Memory Protection Checks: http://people.redhat.com/drepper/selinux-mem.html
comments powered by Disqus
Mehr zum Thema

Mandatory-Access-Control (MAC) mit SE Linux

Gelangen Eindringlinge erst einmal auf den eigenen Server, steht das angeblich so sichere Linux schnell nicht mehr so gut da. Haben sie erst einmal Root-Rechte, haben sie uneingeschänkten Zugang zu allem. SE Linux schiebt einen zusätzlichen Riegel vor.
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023