SELinux Protokollmeldungen

Eine der wichtigsten Informationsquellen im Zusammenhang mit SELinux sind die Protokolle. Hier erfährt der Administrator, wo SELinux den Zugriff unterbunden hat. Deswegen beschäftigen wir uns zunächst mit diesen Protokollen.

SELinux erzeugt bei fast allen Regelverletzungen Protokollmeldungen. Diese Meldungen werden von dem Audit-Subsystem des Kernels erzeugt und von dem Syslogd-Daemon normalerweise in der Datei /var/log/messages gespeichert:

Aug 24 10:35:23 supergrobi kernel: audit(1156408523.227:485): avc:  denied  { write } for  pid=8430 comm="sshd" name="wtmp" dev=dm-3 ino=6311880 scontext=system_u:system_r:sshd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_log_t:s0 tclass=file

Sobald jedoch der Auditd-Daemon auf Ihrem System aktiv ist, übernimmt dieser an Stelle des Syslogd-Daemon die Meldungen und schreibt sie in die Datei /var/log/audit.log. Der Auditd-Daemon und das Kernel-Audit-Subsystem wird genauer im Anhang besprochen (siehe A). Die gleiche Meldung im Audit-Log sieht folgendermaßen aus:

type=AVC msg=audit(1156408523.227:485): avc:  denied  { write } for  pid=8430 comm="sshd" name="wtmp" dev=dm-3 ino=6311880 scontext=system_u:system_r:sshd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_log_t:s0 tclass=file

Beide Meldungen sind ab dem Schlüsselwort audit identisch. Dass es sich um eine SELinux-Protokollmeldung handelt, erkennen Sie an dem Schlüsselwort avc. Diese Abkürzung steht für den Access-Vector-Cache (siehe auch 17). Der Access-Vector-Cache wertet die Richtlinien aus und gewährt oder verweigert den Zugriff.

Protokollmeldungen können bei zwei Ereignissen erzeugt werden:

• Der Zugriff wird verweigert. Dann wird immer eine denied Meldung erzeugt. In Ausnahmefällen kann die Meldung unterdrückt werden.
• Der Zugriff wird erlaubt. Dann wird normalerweise keine Meldung erzeugt. Es gibt jedoch Regeln, die eine Meldung speziell erzwingen. Diese erzeugen eine granted-Meldung:

Die letzteren Meldungen sind eher selten und werden nur bei besonderen Ereignissen ausgelöst. Ein typisches Ereignis ist ein Neuladen der Policy:

type=AVC msg=audit(1156414643.446:697): avc:  granted  { load_policy } for  pid=8972 comm="load_policy" scontext=root:sysadm_r:load_policy_t:s0-s0:c0.c255 tcontext=system_u:object_r:security_t:s0 tclass=security

Wie müssen Sie die Meldungen nun lesen?

type=AVC msg=audit(1156408523.227:485): avc(1):  denied(2)  { write }(3) for  pid=8430(4) comm="sshd"(5) name="wtmp"(6) dev=dm-3(7) ino=6311880(8) scontext=system_u:system_r:sshd_t:s0-s0:c0.c255(9) tcontext=system_u:object_r:var_log_t:s0(10) tclass=file(11)

Jede Meldung beginnt, wie bereits erwähnt, mit dem Schlüsselwort avc (1). Anschließend kommt entweder granted oder denied (2) gefolgt von dem Zugriff in geschweiften Klammern (3). Hier handelt es sich um einen Schreibzugriff (write). Damit sie prüfen können welcher Prozess den Zugriff durchgeführt hat, folgen die Prozess-ID des Prozesses (4) und der Name des Kommandos (5). Anschließend finden Sie den Namen des Objektes (6) auf das zugegriffen wurde und bei Dateien, Verzeichnissen etc. den Namen des Gerätes (7), auf dem sich das Objekt befindet und seine Inode-Nummer (8). In allen Meldungen finden Sie dann wieder den Security-Context der Quelle (s(ource)context, 9) und den Security-Context des Ziels (t(arget)context, 10) gefolgt von der Objektklasse des Ziels (t(arget)class, 11).

In diesem Fall hat also der Secure-Shell-Daemon (sshd) versucht die Datei (tclass=file) wtmp auf dem Gerät dm-3 zu schreiben. Dabei verwendet der Secure-Shell-Daemon den Typ sshd_t und die Datei hat den Typ var_log_t. Dieser Zugriff wird von den Regeln nicht erlaubt und daher abgelehnt. Eine entsprechende Regel, die diesen Zugriff erlauben würde, ist:

allow sshd_t var_log_t:file { write };

Für die Analyse der Protokollmeldungen stehen auch einige Befehle zur Verfügung, mit denen Sie die Analyse einfacher durchführen können. Der Befehl audit2allow (siehe auch 26.3) ermöglicht es Ihnen direkt aus einer Protokollmeldung die entsprechende Allow-Regel zu erzeugen. Wir werden diesen Befehl im Kapitel 22 näher kennenlernen.

Der Befehl audit2why versucht den Grund einer Meldung zu analysieren. Leider ist dieses Werkzeug nicht sehr intelligent. Im Falle unserer Meldung erhalten wir die folgende Ausgabe:

Aug 24 10:35:23 supergrobi kernel: audit(1156408523.227:485): avc:  denied  { write } for  pid=8430 comm="sshd" name="wtmp" dev=dm-3 ino=6311880 scontext=system_u:system_r:sshd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_log_t:s0 tclass=file
        Was caused by:
                Missing or disabled TE allow rule.
                Allow rules may exist but be disabled by boolean settings; check boolean settings.
                You can see the necessary allow rules by running audit2allow with this audit message as input.

Schließlich steht auch noch ein grafisches Werkzeug für die Analyse der Protokollmeldungen zur Verfügung. Möglicherweise müssen Sie das Paket setools-gui nachinstallieren, um das Programm seAudit auf Ihrem System verwenden zu können. Existiert für Ihre Distribution dieses Paket nicht, können Sie die Werkzeuge auch von der Homepage von Tresys herunterladen (http://oss.tresys.com/projects/setools) und manuell installieren.

Mit seaudit lesen Sie die Protokollmeldungen aus der Datei /var/log/messages oder /var/log/audit/audit.log ein und stellen Sie grafisch dar (siehe Abbildung 20.1).

Abbildung: seAudit stellt die Logmeldungen grafisch dar. Für die Echtzeitüberwachung können Sie den Monitor-Modus aktivieren

Dieses Werkzeug erlaubt es Ihnen auch zwischen der Echtzeitüberwachung und der Offline-Analyse hin- und herzuschalten. Über Toggle Monitor schalten Sie die Echtzeitanzeige an und ab. Dies ist insbesondere von Vorteil, da Sie auch die Sicht auf die Ereignisse modifizieren können. Wählen Sie Modify view und Sie erhalten einen neuen Dialog (siehe Abbildung 20.2), in dem Sie der Sicht zunächst einen Namen geben können und Filter definieren können.

Abbildung: Die Sichten in Seaudit können mächtig editiert und mit Filter versehen werden.

Durch diese Filter erhalten Sie einen wesentlich besseren Überblick über die anfallenden Meldungen (siehe Abbildung 20.3).

Abbildung: Mit den Sichten behalten Sie einen guten Überblick über die anfallenden Meldungen.

Sie können beliebig viele Filter definieren. Diese können Sie verwenden, um Meldungen zu verstecken (Hide) oder anzuzeigen (Show). Dabei können Sie die Filter Und- (All) und Oder-verknüpfen (Any). Auch die Filter können mit Namen versehen werden (siehe Abbildung 20.2). Bei den Filtern können Sie den Security-Context des Subjektes und Objektes seine Objektklasse spezifizieren. Zusätzlich können Sie auf weiteren Reitern IP-Adressen, Ports und Netzwerkschnittstellen, Rechnernamen, Kommandonamen und Pfade angeben. Auf der Registerkarte Other können Sie auch zwischen Denied und granted-Meldungen unterscheiden. Natürlich können Sie die fertigen Sichten auch abspeichern und die Filter auf der Registerkarte Notes kommentieren.

Haben Sie eine Meldung gefunden, die Sie näher interessiert, können Sie direkt aus dem Programm seAudit die Policy laden und die entsprechenden Regeln anzeigen. Hierzu wählen Sie Query Policy und spezifizieren die anzuzeigenden Regeln (siehe Abbildung 20.4).

Abbildung: Mit Seaudit können Sie direkt auch die entsprechenden Regeln der Policy anzeigen.

Hierfür benötigt seAudit lediglich die vorhandene binäre Policy. Möchten Sie nicht die Standard-Policy laden, können Sie über das File-Menü natürlich auch eine andere Policy angeben.

Schließlich können Sie auch direkt über seaudit den Kommandozeilenbefehl seaudit-report aufrufen (siehe 26.20). Hiermit erstellen Sie einen Bericht, der die Meldungen zusammenfasst und sogar in HTML mit einem Stylesheet ansprechend formatieren kann (siehe Abbildung 20.5 und 20.6).

Abbildung 20.5: Seaudit erlaubt auch die direkte Erzeugung von Berichten.

Abbildung: Die Berichte können in HTML mit Stylesheet formatiert werden.

Wenn Sie jedoch nur einige Meldungen für eine spätere Analyse zum Beispiel mit audit2allow exportieren möchten, können Sie das über das Menü View erreichen. Entweder exportieren Sie sämtliche Meldungen in der aktuellen Sicht (Export View) oder Sie wählen zuvor einzelne Meldungen aus und exportieren diese (Export Selected Messages).