Zum Inhalt springen

Linux/SELinux/04/02 Protokolldateien: Unterschied zwischen den Versionen

Aus Foxwiki
K Dirkwagner verschob die Seite Linux/SELinux/DOC/04 Arbeiten mit Linux/SELinux/Protokolldateien nach Linux/SELinux/DOC/04/Protokolldateien, ohne dabei eine Weiterleitung anzulegen
K Textersetzung - „ z. B.“ durch „ beispielsweise“
 
(11 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Navigation|Linux/SELinux/04 Arbeiten mit SELinux|Linux/SELinux/04/03 Hauptkonfigurationsdatei}}
'''Linux/SELinux/04/02 Protokolldateien''' - Fehlermeldungen finden
=== Welche Protokolldatei wird verwendet ===
=== Welche Protokolldatei wird verwendet ===
Unter Red Hat Enterprise Linux sind die Pakete dbus und audit standardmäßig installiert, sofern sie nicht aus der Standard-Paketauswahl entfernt wurden
SELinux-Ablehnungen werden primär über das Linux-Audit-Subsystem protokolliert. Wenn der ''auditd''-Daemon läuft, werden rohe AVC-Meldungen standardmäßig in ''/var/log/audit/audit.log'' geschrieben. Für die Analyse ist diese Datei die wichtigste Quelle.
* Der Setroubleshoot-Server muss über Yum installiert werden (verwenden Sie den Befehl [[yum install setroubleshoot-server]])
 
Zusätzlich können interpretierte Hinweise im Systemprotokoll erscheinen, zum Beispiel über ''setroubleshoot''. Diese Meldungen erleichtern die Einordnung, ersetzen aber nicht die rohe AVC-Meldung.
 
{| class="wikitable options big"
! Quelle
! Inhalt
! Zweck
|-
| ''/var/log/audit/audit.log''
| rohe Audit- und AVC-Meldungen
| erste Quelle für Analyse und Korrelation
|-
| Systemjournal
| interpretierte Meldungen, beispielsweise von ''setroubleshoot''
| schnelle Einordnung und Verweis auf ''sealert''
|}
 
* SELinux prüft Zugriffe erst nach den klassischen Dateirechten. Wird ein Zugriff bereits dort verweigert, entsteht keine SELinux-Ablehnung.
 
=== Beispiel einer AVC-Meldung ===
Eine AVC-Meldung kann beispielsweise wie folgt aussehen:
 
<syntaxhighlight lang="text" copy line highlight="">
type=AVC msg=audit(1710000000.123:321): avc: denied { getattr } for pid=1234 comm="httpd" path="/var/www/html/file1" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file
</syntaxhighlight>
 
Die wichtigsten Bestandteile:
 
{| class="wikitable options big"
! Feld
! Bedeutung
|-
| ''{ getattr }''
| verweigerte Operation
|-
| ''comm="httpd"''
| aufgerufener Prozess
|-
| ''path="/var/www/html/file1"''
| betroffenes Zielobjekt
|-
| ''scontext=...:httpd_t:s0''
| SELinux-Kontext des Prozesses
|-
| ''tcontext=...:samba_share_t:s0''
| SELinux-Kontext des Zielobjekts
|-
| ''tclass=file''
| Objektklasse
|}
 
=== Vollständige SELinux-Meldungen ===
Für die gezielte Auswertung der Audit-Einträge eignet sich ''ausearch'':
 
<syntaxhighlight lang="bash" copy line highlight="">
ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
ausearch -m AVC -i -ts recent
</syntaxhighlight>
 
Ist ''setroubleshoot'' installiert, können zusätzliche Hinweise mit ''sealert'' angezeigt werden. Enthält eine Meldung eine lokale ID, lässt sie sich direkt auflösen:
 
<syntaxhighlight lang="bash" copy line highlight="1">
sealert -l <ID>
</syntaxhighlight>
 
Interpretierte Meldungen von ''setroubleshoot'' lassen sich im Systemjournal anzeigen:
 
<syntaxhighlight lang="bash" copy line highlight="1">
journalctl -t setroubleshoot
</syntaxhighlight>
 
=== Wenn keine Meldungen erscheinen ===
Erscheinen keine AVC-Meldungen, sollten zuerst die üblichen Fehlerquellen geprüft werden:
 
* Läuft ''auditd'' nicht, werden keine rohen Audit-Einträge in ''/var/log/audit/audit.log'' geschrieben.
* Ohne Treffer in ''ausearch'' sollte der blockierte Zugriff erneut ausgeführt und danach erneut gesucht werden.
* Ist ''auditd'' nicht aktiv, können einzelne SELinux-Meldungen noch im Kernel-Puffer sichtbar sein.
 
Praktische Prüfung:
 
<syntaxhighlight lang="bash" copy line highlight="">
systemctl status auditd.service
dmesg | grep -i -e type=1300 -e type=1400
</syntaxhighlight>
 
Für eine dauerhafte Protokollierung kann ''auditd'' aktiviert werden:
 
<syntaxhighlight lang="bash" copy line highlight="">
systemctl enable --now auditd.service
systemctl is-enabled auditd.service
</syntaxhighlight>


Wenn der [[auditd]]-Daemon läuft, wird standardmäßig eine SELinux-Ablehnungsmeldung wie die folgende in [[/var/log/audit/audit.log]] geschrieben
Werden Ablehnungen durch ''dontaudit''-Regeln unterdrückt, lässt sich die Protokollierung kurzfristig erweitern:
type=AVC msg=audit (1223024155.684:49)
avc
denied { getattr } for pid=2000 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=399185 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file


Außerdem wird eine Meldung ähnlich der folgenden in die Datei [[/var/log/message]] geschrieben
<syntaxhighlight lang="bash" copy line highlight="">
7. Mai 18:55:56 localhost setroubleshoot
semodule -DB
SELinux verhindert, dass httpd (httpd_t) „getattr“ auf /var/www/html/file1 (samba_share_t) ausführt
# blockierten Zugriff erneut ausführen
* Für vollständige SELinux-Meldungen
ausearch -m AVC -i -ts recent
führen Sie sealert -l de7e30d6-5488-466d-a606-92c9f40d316d aus
semodule -B
</syntaxhighlight>


In Red Hat Enterprise Linux 7 läuft [[setroubleshootd]] nicht mehr ständig als Dienst
== Weblinks ==
* Es wird jedoch weiterhin zur Analyse der AVC-Meldungen verwendet
Red Hat Documentation:
* Zwei neue Programme dienen dazu, [[setroubleshoot]] bei Bedarf zu starten
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux
* Das Dienstprogramm [[sedispatch]] läuft als Teil des [[audit]]-Subsystems
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/sect-security-enhanced_linux-working_with_selinux-which_log_file_is_used
* Wenn eine AVC-Ablehnungsmeldung zurückgegeben wird, sendet [[sedispatch]] eine Nachricht über [[dbus]]
* https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/security-enhanced_linux/sect-security-enhanced_linux-fixing_problems-sealert_messages
* Diese Nachrichten gehen direkt an [[setroubleshootd]], sofern dieses bereits läuft
Debian Manpages:
* Läuft es nicht, startet [[sedispatch]] es automatisch
* https://manpages.debian.org/testing/auditd/auditd.8.en.html
* Das Dienstprogramm [[seapplet]] läuft in der System-Symbolleiste und wartet auf DBus-Meldungen von [[setroubleshootd]]
* Es öffnet die Benachrichtigungsblase, in der der Benutzer die AVC-Meldungen einsehen kann


; Daemons automatisch starten
{{Navigation|Linux/SELinux/04 Arbeiten mit SELinux|Linux/SELinux/04/03 Hauptkonfigurationsdatei}}
# Um die Daemons [[auditd]] und [ [rsyslog]]-Daemons so zu konfigurieren, dass sie beim Booten automatisch starten, geben Sie als Root-Benutzer die folgenden Befehle ein
sudo systemctl enable auditd.service
sudo systemctl enable rsyslog.service
# Um sicherzustellen, dass die Daemons aktiviert sind, geben Sie an der Shell-Eingabeaufforderung die folgenden Befehle ein
systemctl is-enabled auditd
enabled
systemctl is-enabled rsyslog
enabled
Alternativ können Sie den Befehl [[systemctl status ‚'service-name‘'.service]] verwenden und in der Befehlsausgabe nach dem Schlüsselwort [[enabled]] suchen, zum Beispiel
systemctl status auditd.service | grep enabled
auditd.service – Sicherheitsüberwachungsdienst
Geladen
geladen (/usr/lib/systemd/system/auditd.service; ‚'enabled‘')


Weitere Informationen darüber, wie der [[systemd]]-Daemon Systemdienste verwaltet, finden Sie im Kapitel „Verwaltung von Systemdiensten“ im Systemadministratorhandbuch


[[Kategorie:Linux/SELinux/DOC/04]]
[[Kategorie:Linux/SELinux/04]]

Aktuelle Version vom 16. Juni 2026, 09:28 Uhr

Linux/SELinux/04/02 Protokolldateien - Fehlermeldungen finden

Welche Protokolldatei wird verwendet

SELinux-Ablehnungen werden primär über das Linux-Audit-Subsystem protokolliert. Wenn der auditd-Daemon läuft, werden rohe AVC-Meldungen standardmäßig in /var/log/audit/audit.log geschrieben. Für die Analyse ist diese Datei die wichtigste Quelle.

Zusätzlich können interpretierte Hinweise im Systemprotokoll erscheinen, zum Beispiel über setroubleshoot. Diese Meldungen erleichtern die Einordnung, ersetzen aber nicht die rohe AVC-Meldung.

Quelle Inhalt Zweck
/var/log/audit/audit.log rohe Audit- und AVC-Meldungen erste Quelle für Analyse und Korrelation
Systemjournal interpretierte Meldungen, beispielsweise von setroubleshoot schnelle Einordnung und Verweis auf sealert
  • SELinux prüft Zugriffe erst nach den klassischen Dateirechten. Wird ein Zugriff bereits dort verweigert, entsteht keine SELinux-Ablehnung.

Beispiel einer AVC-Meldung

Eine AVC-Meldung kann beispielsweise wie folgt aussehen:

type=AVC msg=audit(1710000000.123:321): avc: denied { getattr } for pid=1234 comm="httpd" path="/var/www/html/file1" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:samba_share_t:s0 tclass=file

Die wichtigsten Bestandteile:

Feld Bedeutung
{ getattr } verweigerte Operation
comm="httpd" aufgerufener Prozess
path="/var/www/html/file1" betroffenes Zielobjekt
scontext=...:httpd_t:s0 SELinux-Kontext des Prozesses
tcontext=...:samba_share_t:s0 SELinux-Kontext des Zielobjekts
tclass=file Objektklasse

Vollständige SELinux-Meldungen

Für die gezielte Auswertung der Audit-Einträge eignet sich ausearch:

ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
ausearch -m AVC -i -ts recent

Ist setroubleshoot installiert, können zusätzliche Hinweise mit sealert angezeigt werden. Enthält eine Meldung eine lokale ID, lässt sie sich direkt auflösen:

sealert -l <ID>

Interpretierte Meldungen von setroubleshoot lassen sich im Systemjournal anzeigen:

journalctl -t setroubleshoot

Wenn keine Meldungen erscheinen

Erscheinen keine AVC-Meldungen, sollten zuerst die üblichen Fehlerquellen geprüft werden:

  • Läuft auditd nicht, werden keine rohen Audit-Einträge in /var/log/audit/audit.log geschrieben.
  • Ohne Treffer in ausearch sollte der blockierte Zugriff erneut ausgeführt und danach erneut gesucht werden.
  • Ist auditd nicht aktiv, können einzelne SELinux-Meldungen noch im Kernel-Puffer sichtbar sein.

Praktische Prüfung:

systemctl status auditd.service
dmesg | grep -i -e type=1300 -e type=1400

Für eine dauerhafte Protokollierung kann auditd aktiviert werden:

systemctl enable --now auditd.service
systemctl is-enabled auditd.service

Werden Ablehnungen durch dontaudit-Regeln unterdrückt, lässt sich die Protokollierung kurzfristig erweitern:

semodule -DB
# blockierten Zugriff erneut ausführen
ausearch -m AVC -i -ts recent
semodule -B

Red Hat Documentation:

Debian Manpages: