Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
documentation.suse.com / Fehlersuche bei SELinux

Fehlersuche bei SELinux

Veröffentlicht: 20.03.2025
WAS?

Ein System mit SELinux im Modus enforcing kann zu Zugriffsverweigerungen führen, die die ordnungsgemäße Ausführung von Anwendungen verhindern können. Sie können audit2allow oder setroubleshoot benutzerfreundlich zum Analysieren von Verweigerungsmeldungen verwenden.

WARUM?

Dieser Artikel enthält Anweisungen, wie Sie durch SELinux verursachte Zugriffsverweigerungen beheben können, ohne die Sicherheit Ihres Systems zu beeinträchtigen.

AUFWAND

Es dauert etwa 30 Minuten, den Artikel zu lesen.

ZIEL

Sie können eines der nachfolgend beschriebenen Tools verwenden, um SELinux-Verweigerungen zu debuggen.

ANFORDERUNGEN

  • Ein laufendes System mit aktiviertem SELinux.

1 Die /var/log/audit/audit.log-Datei

 

Wenn SELinux der Grund dafür ist, dass etwas nicht funktioniert, wird standardmäßig eine entsprechende Protokollmeldung an die Datei /var/log/audit/audit.log gesendet.

Anmerkung
Anmerkung: Datei /var/log/audit/audit.log leer

Wenn Sie eine leere Datei /var/log/audit/audit.log sehen, bedeutet dies normalerweise, dass der auditd-Dienst nicht ausgeführt wird. Gehen Sie in diesem Fall folgendermaßen vor:

  1. Starten Sie den Dienst auditd: 

                > 
            sudo
            systemctl start auditd

  2. Aktivieren Sie den Dienst in den Zielen Ihres Systems mit 

                > 
            sudo
            systemctl enable auditd

In der Datei /var/log/audit/audit.log werden Meldungen über Zugriffsverweigerungen, Dienstereignisse usw. gespeichert.

In Beispiel 1: „Beispielzeilen von /etc/audit/audit.log“ sehen Sie ein Teilbeispiel für den Inhalt von /var/log/audit/audit.log.

Beispiel 1: Beispielzeilen von /etc/audit/audit.log
 
type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success
type=AVC msg=audit(1348173901.081:292): avc:  denied  { write } for  pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:293): avc:  denied  { remove_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:294): avc:  denied  { unlink } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:295): avc:  denied  { rename } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:296): avc:  denied  { add_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:297): avc:  denied  { create } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:298): avc:  denied  { write open } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316

Eine einzelne Meldung sieht wie folgt aus: 

  type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file

Jede Zeile der Meldung kann in Abschnitte unterteilt werden. Die Abschnitte in der letzten Zeile lauten beispielsweise:

type=AVC:

Jede SELinux-bezogene Auditprotokollzeile beginnt mit der Typidentifikation, z. B. type=AVC Beachten Sie, dass eine Meldung mit dem type=SYSCALL, die auf eine Meldung mit einem anderen Typ folgt und den gleichen Wert von msg hat, weitere Informationen zum Ereignis enthalten kann.

msg=audit(1348173901.309:300):

Dies ist der Zeitstempel, der in Epochenzeit geschrieben wird, der Anzahl der Sekunden, die seit dem 1. Januar 1970 vergangen sind. Sie können mit date -d auf dem Teil bis zum Punkt in der Epochenzeit- Schreibweise herausfinden, wann das Ereignis stattgefunden hat: 

> date -d @1348173901
Thu Sep 20 16:45:01 EDT 2012
avc: denied { append }:

Die spezifische Aktion, die abgelehnt wurde. In diesem Fall hat das System das Anhängen von Daten an eine Datei verweigert. Beim Durchsuchen der Überwachungsprotokolldatei können Sie andere Systemaktionen sehen, z. B. write open, getattr und mehr.

for pid=1316:

die Prozess-ID des Kommandos oder Prozesses, der die Aktion initiiert hat

comm="rsyslogd":

das spezifische Kommando, das dieser PID zugeordnet war

name="smartmontools":

den Namen des Gegenstands der Maßnahme

dev=sda6 ino=582296:

das Blockgerät und die Inode-Nummer der Datei, die betroffen war

scontext=system_u:system_r:syslogd_t:

der Quellkontext, d. h. der Kontext des Initiators der Aktion

tclass=file:

eine Klassenidentifikation des Subjekts

2 Analysieren von /var/log/audit/audit.log mit audit2allow

 

Anstatt die Ereignisse in /var/log/audit/audit.log selbst zu interpretieren, können Sie das Kommando audit2allow verwenden.

Das Kommando hilft bei der Analyse der kryptischen Protokollmeldungen in /var/log/audit/audit.log. Eine audit2allowFehlersuchesitzung besteht immer aus drei verschiedenen Kommandos. Erstens würden Sie audit2allow -w -a verwenden, um die Auditinformationen besser lesbar zu machen. audit2allow -w -a funktioniert standardmäßig mit der Datei audit.log. Wenn Sie eine bestimmte Meldung in der Datei audit.loganalysieren möchten, kopieren Sie sie in eine temporäre Datei und analysieren Sie die Datei mit: 

      > 
      sudo
      audit2allow -w -i FILENAME
Beispiel 2: Analysieren von Audit-Meldungen
 
> sudoaudit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316
comm="rsyslogd" name="acpid" dev=sda6 ino=582296
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
Dies wurde verursacht durch:

Eine Regel zur Erzwingung fehlender Typen (TE).

Führen Sie zum Generieren eines ladbaren Moduls, das diesen Zugriff ermöglicht, das folgende Kommando aus: 

            > 
            sudo
            audit2allow

Um herauszufinden, welche spezifische Regel den Zugriff verweigert hat, können Sie mit audit2allow -a die Erzwingungsregeln für alle Ereignisse anzeigen, die in der Datei audit.log protokolliert wurden, oder mit audit2allow -i FILENAME für Meldungen, die Sie in einer bestimmten Datei gespeichert haben:

Beispiel 3: Anzeigen, welche Zeilen den Zugriff verweigern
 
> sudoaudit2allow -i testfile
#============= syslogd_t ==============
allow syslogd_t apmd_log_t:file append;

Wenn Sie ein SELinux-Modul mit dem Namen mymodule erstellen möchten, das Sie laden können, um den zuvor verweigerten Zugriff zuzulassen, führen Sie das folgende Kommando aus: 

      > 
      sudo
      audit2allow -a -R -M mymodule

Wenn Sie dies für alle Ereignisse tun möchten, die in der Datei audit.log protokolliert wurden, verwenden Sie die Kommandoargumente -a -M. Wenn Sie dies nur für bestimmte Meldungen tun möchten, die sich in einer bestimmten Datei befinden, verwenden Sie -i -M wie im folgenden Beispiel:

Beispiel 4: Erstellen eines Richtlinienmoduls, das eine zuvor verweigerte Aktion zulässt
 
> sudoaudit2allow -i testfile -M example
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i example.pp

Wie im Kommando audit2allow angegeben, können Sie dieses Modul jetzt mit dem Kommando semodule -i ausführen, gefolgt vom Namen des Moduls, das audit2allow für Sie erstellt hat (example.pp im obigen Beispiel).

3 Analysieren von AVC-Meldungen mit setroubleshoot

 

Mit dem Tool setroubleshoot können Sie AVC-Verweigerungsmeldungen auf benutzerfreundliche Weise analysieren.

3.1 Übersicht über setroubleshoot

 

3.1.1 Was ist setroubleshoot?

 

setroubleshoot ist ein Tool, das SELinux-Audit-Ereignisse vom Kernel erfasst und analysiert. Wenn ein solches Ereignis eintritt, wird der Administrator mit setroubleshoot informiert.

3.1.2 setroubleshoot-Komponenten

 

Der SELinux-Fehlersucheprozess umfasst die folgenden Komponenten, die alle standardmäßig unter SUSE Linux Micro installiert sind.

  • setroubleshoot-server bietet die folgenden Tools:

    • setroubleshootd: der Hauptdaemon, der eingehende Anfragen und Plugin-Definitionen verarbeitet. Der Daemon wird bei Bedarf aktiviert und muss nicht über den systemd-Dienst ausgeführt werden. Es kann nur von einem privilegierten Benutzer und einem dedizierten setroubleshoot-Benutzer verwaltet werden.

    • eine Datenbank mit Warnungen in der Datei /var/lib/setroubleshoot/setroubleshoot_database.xml

    • sealert: eine Kommandozeilenschnittstelle zur Analyse der /var/log/audit.log

    • sedispatch: ein Audit-Dispatcher, der SELinux AVC-Meldungen scannt und sie in eine DBus-Meldung umwandelt, die dann an den Daemon übergeben wird.

  • setroubleshoot-plugins: die Plug-ins werden für die Analyse von AVC-Meldungen verwendet und bieten Vorschläge zur Behebung von Problemen.

3.1.3 Wie funktioniert setroubleshoot?

 

setroubleshoot besteht aus einem Daemon und Analyse-Plugins. Wenn ein Plugin ein Problem erkennt, wird es an den Daemon gemeldet, der dann prüft, ob es sich um ein bekanntes Problem handelt. Wenn nicht, wird das neue Problem zusammen mit einem Lösungsvorschlag zur Datenbank hinzugefügt.

3.1.4 Vorteile von setroubleshoot

 

setroubleshoot bietet die folgenden Funktionen, um Ihnen bei der Lösung von Problemen auf Ihren SELinux-gesicherten Systemen zu helfen:

  • Senden von Warnungen an den Administrator, wenn eine AVC-Verweigerung vorliegt.

  • Automatische Analyse von AVC-Verweigerungen.

  • Vorschlagen möglicher Korrekturen, z. B. Anpassen der Systemkonfiguration oder Installieren von Aktualisierungen usw.

  • Durchsuchen früherer Warnungen.

3.2 Konfigurieren von setroubleshoot

 

Auch wenn die Konfiguration von setroubleshoot nicht angepasst werden muss, können Sie mit bestimmten Anwendungsfällen konfrontiert werden, in denen Sie die Standardeinstellungen ändern müssen. In den folgenden Abschnitten werden die üblichen Anwendungsfälle beschrieben.

Die Konfigurationsdatei für setroubleshoot ist /etc/setroubleshoot. In der Regel müssen Sie abgesehen vom Festlegen der E-Mail-Benachrichtigungen keine Änderungen an der Konfiguration vornehmen. Wenn Sie jedoch die Konfiguration ändern müssen, können Sie entweder die Datei bearbeiten oder mit dem Kommando setroubleshootd ein bestimmtes Element konfigurieren. Die Kommandosyntax lautet wie folgt: 

        # 
        setroubleshootd -c
SECTION.OPTION=VALUE

Führen Sie beispielsweise zum Festlegen der Option from_address das Kommando wie folgt aus: 

        # 
        setroubleshootd -c
email.from_address="example@mail.com"

3.2.1 Konfigurieren der Protokollierungsstufe setroubleshoot

 

Die Standardprotokollierungsstufe (der Wert von sealert_log und setroubleshootd_log) ist auf warning festgelegt. Sie können den Wert jedoch auf einen der folgenden Werte festlegen:

critical

Es werden nur schwerwiegende Fehler protokolliert, die die Funktion des Systems beeinträchtigen.

error

Schwerwiegende Fehler, die das System beeinflussen können, werden gemeldet.

warning

Ein Hinweis darauf, dass etwas Unerwartetes passiert ist oder dass in naher Zukunft ein Problem auftreten könnte. Das System funktioniert jedoch wie erwartet.

info

Eine Bestätigung, dass das System ordnungsgemäß läuft, wird protokolliert.

debug

Detaillierte Informationen zu Debugging-Zwecken werden protokolliert.

3.2.2 Konfigurieren von setroubleshoot zum Senden von E-Mail-Benachrichtigungen

 

setroubleshoot kann Ihnen E-Mail-Benachrichtigungen senden, wenn es eine AVC-Verweigerung im System gibt.

Gehen Sie wie folgt vor, um diese Benachrichtigungen zu erhalten:

  1. Öffnen Sie den Ordner /etc/setroubleshoot/setroubleshoot.conf.

  2. Passen Sie in der Datei die folgenden Konfigurationselemente an Ihre Anforderungen an:

    smtp_host

    Wenn der SMTP-Server nicht auf dem lokalen Host ausgeführt wird, geben Sie die Serveradresse ein.

    smtp_port

    Der Standardwert ist 25. Normalerweise muss dieser Wert nicht angepasst werden.

    from_address

    Fügen Sie die Absenderadresse hinzu.

    subject

    Konfigurieren Sie einen generischen Betreff für alle Meldungen.

    recipients_filepath

    Geben Sie den Speicherort der Liste der Benachrichtigungsempfänger an.

    use_sendmail

    Legen Sie true fest, wenn Sie SendMail verwenden.

  3. Erstellen Sie die E-Mail-Empfängerdatei in dem durch die Option recipients_filepath definierten Pfad (standardmäßig /var/lib/setroubleshoot/email_alerts-recipients).

    Jede E-Mail-Adresse muss in einer eigenen Zeile stehen. Kommentare werden mit dem Symbol # gekennzeichnet.

3.2.3 Konfigurieren der setroubleshoot-Datenbank

 

Sie können die Anzahl der Datensätze in der setroubleshootd-Datenbank, ihren Speicherort oder das Dateinamenpräfix ändern.

database_dir

Geben Sie einen absoluten Pfad zu dem Verzeichnis an, in dem sich die XML-Datenbankdatei befinden soll.

filename

Konfigurieren Sie ein benutzerdefiniertes Präfix des Datenbankdateinamens. Der Dateiname sieht dann wie folgt aus: FILENAME_PREFIX_database.xml

max_alerts

Definiert die maximale Anzahl von Datensätzen in der Datenbank. Geben Sie 0 für eine unbegrenzte Anzahl von Datensätzen an.

max_alert_age

Warnungen, die älter als der festgelegte Grenzwert sind, werden aus der Datenbank gelöscht. Sie können die Einheiten: Jahr, Monat, Tag, Stunde, Minute und Sekunde auch im Plural verwenden und Sie können beispielsweise mehr als eine Einheit verwenden, zum Beispiel 3 weeks 2 days, was 23 Tagen entspricht. Wenn es leer gelassen wird, gibt es keine Begrenzung.

3.2.4 Konfigurieren von setroubleshoot zum Erfassen von Informationen von Remoteservern

 

Sie können setroubleshoot so konfigurieren, dass SELinux-Audit-Daten von Remoteservern erfasst werden. Konfigurieren Sie dazu die Adressliste.

[listen_for_client] address_list

Auf der Serverseite.

[client_connect_to] address_list

Auf der Client-Seite.

Die Adressen in der Liste haben das folgende Format: 

          [{FAMILY}]ADDRESS[:PORT_NUMBER]

{FAMILY} ist dabei {inet} oder {unix}%{path}s. Wenn die Adressfamilie inet ist, können Sie optional eine Portnummer angeben, andernfalls wird die Portnummer auf die in der Konfigurationsoption default_port angegebene Standardnummer festgelegt. Beim Standardwert {unix}%{path}s hostname wird auf dem lokalen Unix-Domänen-Socket überwacht.

3.3 Ausführen der Analyse /var/log/audit/audit.log

 

Führen Sie das folgende Kommando aus, damit das Tool setroubleshoot die Datei des Audit-Protokolls analysiert: 

        > 
        sudo
        sealert -a /var/log/audit/audit.log

In der folgenden Beispielausgabe sind dem SSHD-Dienst zwei Portwerte zugewiesen: 

100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing sshd from name_bind access on the tcp_socket port 2222.

*****  Plugin bind_ports (92.2 confidence) suggests   ************************ 

If you want to allow sshd to bind to network port 2222
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 2222  1
    where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_port_t.

*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************

If you want to allow nis to enabled
Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.

Do
setsebool -P nis_enabled 1

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that sshd should be allowed name_bind access on the port 2222 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Additional Information:
...

First Seen                    2024-02-07 14:26:27 UTC
Last Seen                     2024-02-08 03:30:12 UTC
Local ID                      b5cbdd75-3f8d-425d-af75-f6cbf1540ffd 

Raw Audit Messages
type=AVC msg=audit(1707363012.797:25): avc:  denied  { name_bind } for  pid=841 comm="sshd" src=2222 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0


Hash: sshd,sshd_t,unreserved_port_t,tcp_socket,name_bind

1

Das bind_ports-Plugin bietet hier die am besten geeignete Lösung für das Problem.